A lightweight, fast and functional framework for PHP 5.3
Posts tagged Cache
Why use a PHP accelerator?
11 year ago
To understand how a PHP accelerator works the best place to start is looking at how PHP code is executed by the web server. In it’s simplest form it is something like this:
Open PHP file(s) -> Parse/Compile PHP code to bytecode -> Execute bytecode
Generally what a PHP accelerator will do is store the compiled bytecode either on disk or in shared memory which almost completely eliminates the first to execution steps above. Generally the process to load a page stored in cache will be as follows:
Check file modification time of original script -> Read file from cache -> Execute bytecode
Using an accelerator with PHP can produce some fairly substantial speed improvements by removing the need to parse/compile every script prior to execution. To demonstrate this improvement with an example, the graph below shows the results of the Hello World benchmark, from the benchmarks section of this site:
The blue bars are a standard PHP configuration without any optimisation.
The red bars are when Zend Optimizer+ is enabled within Zend Server CE.
In this example it is evident that with bytecode caching enabled, in this case using Zend Optimizer+, there is a considerable speed increase for every framework tested for this benchmark.
Optimising ini parsing
01 year ago
A great way to store application config, but unfortunately a better way of slowing down the application. Parsing and accessing ini files is somewhat of a heavy process, here is a webgrind output using a stripped down version of the Zend Framework Zend_Config_Ini class:
The main reason for the long processing time of these functions is that they are riddled with recursive functions, which quickly add up. Unfortunately there is little that can be done about the processing time, but there are other possibilities.
The first and most obvious optimisation is to cache the parsed config file, completely eliminating the processing overhead. By default all config files are parsed and saved in a serialised state in the cache directory, this can be switched for Memcache and possibly SHM at a later stage.
The second optimisation that provides a nice speed boost is to change the way the data is stored, multiple calls to the __get magic method soon start to add up and become a bottleneck. For this reason I changed the big array of objects into a simple array structure, leaving the __get magic method so that the top level configuration data can still be accessed in an object format.
For example to access a field called param within session configuration data from the parsed config in LiteMVC we can do the following:
$config = new LiteMVC\App\Config\Ini(‘config.ini’);
$sessionConfig = $config->session;
$sessionParam = $sessionConfig['param'];
$sessionConfig = $config->session;
$sessionParam = $sessionConfig['param'];
This maintains a nice level of usability while almost completely eliminating data access processing overheads. As often using Zend Framework it’s necessary to use the toArray method (another recursive function) this is also completely eliminated as data is already in array form.
Here is a webgrind output showing the new ini parser with file caching, taking just 367 microseconds to load the configuration:
