Original article: http://www.symfony-project.com/book/1_0/18-Performance
Clearing Selective Parts of the Cache
During application development, you have to clear the cache in various situations:
- When you create a new class: Adding a class to an autoloading directory (one of the project's
lib/ folders) is not enough to have symfony find it automatically. You must clear the autoloading configuration cache so that symfony browses again all the directories of the autoload.yml file and references the location of autoloadable classes--including the new ones. - When you change the configuration in production: The configuration is parsed only during the first request in production. Further requests use the cached version instead. So a change in the configuration in the production environment (or any environment where
SF_DEBUG is turned off) doesn't take effect until you clear the cached version of the file. - When you modify a template in an environment where the template cache is enabled: The valid cached templates are always used instead of existing templates in production, so a template change is ignored until the template cache is cleared or outdated.
- When you update an application with the
sync command: This case usually covers the three previous modifications.
The problem with clearing the whole cache is that the next request will take quite long to process, because the configuration cache needs to be regenerated. Besides, the templates that were not modified will be cleared from the cache as well, losing the benefit of previous requests.
That means it's a good idea to clear only the cache files that really need to be regenerated. Use the options of the clear-cache task to define a subset of cache files to clear, as demonstrated in Listing 18-14.
Listing 18-14 - Clearing Only Selective Parts of the Cache
// Clear only the cache of the myapp application
> symfony clear-cache myapp
// Clear only the HTML cache of the myapp application
> symfony clear-cache myapp template
// Clear only the configuration cache of the myapp application
> symfony clear-cache myapp config
You can also remove files by hand in the cache/ directory, or clear template cache files selectively from the action with the $cacheManager->remove() method, as described inChapter 12
Note:
1. We can use $cacheManager->remove() to clear cache after we deployed a new version product.
2. write code to generate models from database, and then call $cacheManager->remove() to clear cache.
#server-id = 1
log-bin = /var/log/mysql/mysql-bin.log
#if you set the expire_logs_days = x var in the [mysqld] section of your my.cnf it will automatically rotate your bin logs after x days.
expire_logs_days = 30
#it will create a new log file when the current file reach the specified size.
max_binlog_size = 100M
Create a file backup_db.sh, and paste the following contents:
#get the first parameter as the database name
DATABASE=$1
#if no database specified, then you can set the default one
if [ -z $DATABASE ]; then
DATABASE=default_database_name_here
fi
#mysql user and password to backup the database.
MYSQLUSER=mysql_user
MYSQLPWD=mysql_password
#path to backup
ARCHIVEPATH=~/backup/db_backup
DATE=`date +%Y%m%d`
YEAR=`date +%Y`
MONTH=`date +%m`
FOLDER_MONTH=$ARCHIVEPATH/$YEAR$MONTH
if [ ! -d $FOLDER_MONTH ]; then
echo "mkdir $FOLDER_MONTH"
mkdir $FOLDER_MONTH
fi
# Backup
echo "mysqldump -u$MYSQLUSER -p$MYSQLPWD $DATABASE | gzip > $FOLDER_MONTH/$DATABASE-$DATE.sql.gz"
mysqldump -u$MYSQLUSER -p$MYSQLPWD $DATABASE | gzip > $FOLDER_MONTH/$DATABASE-$DATE.sql.gz
and you can add the script to cron job under *nix and schedule under windows:
*nix:
Save the following text in file: db_backup.at
10 * * * * ~/backup/backup_db.sh databasename
and call
You need to change the period to run the script for your business, e.g. each day, each week etc.
