Revision as of 14:43, 22 May 2009

A PHP Cache Overview and Cache Tuning

In computers systems, some facets such as memory capacity, memory and CPU cycle times, disk capacity have roughly followed Moore's Law over the last four decade whilst others (typically where physics introduces hard constraints) have barely maintained a steady linear improvement. A good example here is hard disk access times which have barely improved by an order of magnitude at the same time as memory capacities have improved by six orders. Caching Technologies are commonly introduced to mitigate and sometime effectively eliminate the consequences of these linear constraints, and in a modern computer system there can be many layers of caching going on. If you are not careful, the cache control systems can 'fight' and in the worst case you can be hit by cache coherency issues.

This paper investigates how these issues impact the performance of the phpBB V3.0.4 OpenOffice.org user forums.

System Caches

• PHP Cache

The PHP architecture splits the execution of PHP code into two stages: the compilation of source into bytecode and its subsequent execution. This facilitates caching within Apache so that the relatively expensive compile operations can be carried out on a just-in-time basis and stored in a cache. Since complex applications such as phpBB, Drupal and MediaWiki have a large source base, compilation would normally take perhaps 50-75% of CPU cycles and therefore an effective caching strategy can result in a 2-4 x decrease in CPU loading [1],[2]. There are a number of PHP accelerators avaialble but since our forums run on a Solaris Coolstack (CSK) stack, I have adopted the APC cache which is included in the CSK 1.3.1 distribution.

Enabling the APC cache will by default cause any compiled code to be loaded into an LRU cache, and on our system I have initially allocated 64Mb to this cache. The APC can also store and retrieve data by key.

• MySQL Cache

The MySQL database engine maintains a number of caches to accelerate performance: the main caches buffer key indexes in memory, but data rows, execution plans and query results are also cached. The MySQL query cache on our server is currently configured at 32Mb, The caching algorithm [3] is actually very similar to one I discuss below for phpBB SQL caching, and on our system cache hit rates are over 75%.

• File System Cache

*nix file systems maintain large directory and buffer caches in memory [4]. These enable very efficient access to frequently used files and in such cases can obviate the need for disk I/O altogether. However, in order to maintain file system on-disk integrity any file updates do have to be flushed back to disk. Because such writes are asynchronous to the application, under normal circumstances this will now slow the application, except of course, where the application reaches the tipping point where the demand flush rate exceeds the corresponding seek / transfer rate on the physical device and the application becomes I/O bound at that point.

Caches Used in the phpBB Application

Any time phpBB executes a SQL query, style template, or dataset retrieval, it creates an md5 of the sql query / tempate and stores this under the name sql_<md5Value> in the cache (or euqivalent for the other types). Before executing the query, it does an existence check for the file andexecutes an @include it to evaluate it. PHP loades the cached bytecode version instead. Here is a typical example

      <?php
       /* SELECT COUNT(DISTINCT s.session_ip) as num_guests FROM phpbb_en_sessions s \
          WHEREs.session_user_id = 1 AND s.session_time >= 1242322740 AND s.session_forum_id = 61   */
       $expired = (time() > 1242323134) ? true : false;
       if ($expired) { return; }
       $this->sql_rowset[$query_id] = unserialize('a:1:{i:0;a:1:{s:10:"num_guests";s:1:"0";}}');
       ?>

This code sets the boolean $expired and if false then also returns the results set. If true or the file doesn't exist then the execution does the SQL query then creates this file (but only for what the application deems as reusable queries). With this phpBB cache the results are latched for a specific time (in this example the expiry time was some 6 mins after the start of the session) even if the underlying DB data has changed. Thanks to the APC, the code for this is also cached to executing this is quick. This approach is different to the MySQL cache, where the execution plan for each SQL queries is cached in an LRU buffer. This saves parse costs, but the query is still re-evaluated each call.