In this recipe, we will see how to configure Yii for best performances and will see some additional principles of building responsive applications. These principles are both general and Yii-related. Therefore, we will be able to apply some of these even without using Yii.
- Install APC (http://www.php.net/manual/en/apc.installation.php).
- Generate a fresh Yii application using
yiic webapp.
Carry out the following steps:
- First, we need to turn off the debug mode. This can be done by editing
index.phpas follows:defined('YII_DEBUG') or define('YII_DEBUG',false); - The next step is to use
yiilite.php. Again, we need to editindex.phpand change the following code line:$yii=dirname(__FILE__).'/../framework/yii.php';
To the following code line:
$yii=dirname(__FILE__).'/../framework/yiilite.php';
- Now we will move on to
protected/config/main.phpand make some changes:return array( // ... // application components 'components'=>array( // ... 'db'=>array( 'connectionString' => 'mysql:host=localhost;dbname=test', 'username' => 'root', 'password' => '', 'charset' => 'utf8', 'schemaCachingDuration' => 180, ), 'session' => array( 'class' => 'CCacheHttpSession', ), 'cache' => array( 'class' => 'CApcCache', ), ), // ... ); - That's it! Now we don't have to worry about the overhead of Yii itself and can focus on our application.
When YII_DEBUG is set to false, Yii turns off all the trace level logging, uses less error handling code, stops checking the code (for example, Yii checks for invalid regular expressions in router rules), and uses minified JavaScript libraries.
yiilite.php contains the most commonly executed Yii parts. By using it, we can avoid including the extra script and use less memory for APC cache.
Now we will review the additional component configuration that we performed:
'db'=>array( 'connectionString' => 'mysql:host=localhost;dbname=test', 'username' => 'root', 'password' => '', 'charset' => 'utf8', 'schemaCachingDuration' => 180, ),
Setting schemaCachingDuration to a number of seconds allows caching the database schema used by Yii's Active Record. This is highly recommended for production servers and it significantly improves the Active Record performance. In order for it to work, you need to properly configure the cache component as follows:
'cache' => array( 'class' => 'CApcCache', ),
The APC cache is one of the fastest cache solutions if you are using a single server. Enabling cache also has a positive effect on other Yii components. For example, Yii router or urlManager starts to cache routes in this case.
Finally, we configure the session component as follows:
'session' => array( 'class' => 'CCacheHttpSession', ),
The preceding code enables storing sessions in APC, which is significantly faster than the default file-based session handling.
Of course, you can get into a situation where the preceding settings will not help to achieve sufficient performance level. In most cases, it means either that the application itself is a bottleneck or you need more hardware.
Server-side performance is only one of the things that affects the overall performance. By optimizing the client side (such as serving CSS, images, and JavaScript files), proper caching and minimizing the amount of HTTP requests can give a good visual performance gain even without optimizing the PHP code.
Some things are better done without Yii. For example, image resizing on the fly is better done in a separate PHP script in order to avoid the extra overhead.
Use query builder or SQL in performance critical application parts. Generally, AR is most useful when adding and editing records, as it adds a convenient validation layer, and is less useful when selecting records.
A database can become a bottleneck in a second if a developer accidentally forgets to add an index to a table that is being read often or vice versa, or adds too many indexes to a table we are writing to very often. The same goes for selecting unnecessary data and unneeded JOINs.
If you can avoid running a heavy process in every page load, it is better to do so. For example, it is good practice to save or cache results of parsing the markdown text, purifying it (this is a very resource intensive process) once, and then using the ready-to-display HTML.
Sometimes there is too much processing to handle immediately. It can be building complex reports or just simply sending e-mails (if your project is heavily loaded). In this case, it is better to put it into a queue and process it later by using cron or other specialized tools.
For further information, refer to the following URL: