Using APC correctly

APC (Alternative PHP Cache) is one of the orthogonal tools you can use to speed up the execution of PHP code. This article explains from scratch the correct use of APC's system cache (not touching the user cache, which is just a standard key/value map). APC has also other features like upload progress support, but the system cache is its main features and has such a little footprint on your code that you should throw an apc.php file to everyone picking on you for writing strings in single or double quotes.

Applicability

The system cache retains in memory an abstract representation of the content of source files (a data structure whose elements are called *opcodes*). By caching the result of these operations, the overhead you avoid is due to:

• locating and reading a .PHP file on the disk (or whatever filesystem you're using)
• parsing and compiling the file to produce an executable representation.

The savings are reflected in term of time and of resource utilization: requests are served earlier because execution can start sooner, and the utilization of the CPU and drives decreases, meaning that you can serve more simultaneous requests.

Note that if you enable APC for the command line, this won't result in a performance improvement as there is no shared process that can keep the cache running between executions. Moreover, the Apache cache will be separated from the command line one: to manage or clear the former you have to call apc_*() functions inside a script executed through HTTP, as calling them in a cli script would only clear this separate cache. Your options are:

• not enabling APC (perfectly fine for development on local servers)
• reset the cache after a build
• configure APC to check by itself (more on this later)

APC will make your code faster only if you have a bottleneck into the webserver's capability for loading files and parsing them: chances are that your database calls of those 10 web services you access in your script are going to be a much larger source of latency. That said, APC enabled with the default configuration usually does not hurt: you turn it on and forget about it, enjoying a performance improvement between 0% and 50% in terms of request execution time.

Installation

APC is not bundled with PHP (yet?), but installing it is a matter of executing:

sudo pecl apc

which will compile the extension on a Unix system and in most cases add an empty configuration file that just loads the extension in Apache.

An apc.php file is also shipped (in .gz form): you can decompress this file and place it inside a document root to see some statistics and graphs about the cache's performance and current entries. You can even search single files to check their presence in the cache along with temporal information.

Configuration

Configuration directives for APC should go into an apc.ini file (e.g. in /etc/php5/conf.d/apc.ini), or directly into the php.ini if it's monolithic.
This file should at least contain the line:

extension=apc.so

to load the extension.

apc.shm_size=256M

will tell APC the amount of RAM it can use. This is a statically allocated segment that only APC could write on, so it can be wasted RAM if you do not have so many source files to store.

apc.filters=*.phtml,*Test.php

is a comma-separated list of files to exclude from caching, in case they would only eat up memory but not provide a performance improvement due to a very rare access.

apc.stat=0

configures APC to still hit the filesystem when enabled, to check whether a cached file was modified after its caching. This setting is on by default and trades off a bit of performance to avoid cache staleness at all costs.

If you disable stat, you will have to call apc_clear_cache() manually or restart Apache after each file change. I'm not a filesystem expert, but if you always access the same files their inode's content should be cached in RAM by the operating system anyway, so the default setting could be the best fit.

apc.stat_ctime=1

modifies APC's behavior to check the ctime instead of the mtime. The ctime (creation/change) of a file is updated every time a file is copied or its permissions are changed (since they reside in the inodes of the file). The mtime is reset only when the file is actually modified: unzipping a file or rsyncing it may not affect mtime.

For this reason, ctime causes more false positives (that have to be cached again) but it's more reliable against all deployment methods which may not affect mtime.