Before reading this post, I recommend going over part 1 PHP OPCodes Cached with APC – part 1
In the first part we tackled what OPCodes are and how APC helps us streamline webserver performance by caching recurring script execution.
In this second part, we will mostly look at the APC configuration main variable and thus further understand how the APC engine works.
**APC cache size and shared memory
By default this value is set to ‘1’; that is so say, there would be only one shared memory segment to allocate to the cache
This is the size in MB of each shared memory segment. The default is of 30Mb.
Please note that you cannot set a higher value than the maximum size of shared memory segment defined in your kernel distribution.
You can limit the number of files to be cached
In Part 1 we talked about the User Data Cache, used to cache variables, results.. With this variable, you can limit the number of entries in the User Data Cache.
As we discussed earlier, APC loads the OPcode from shared memory; but before doing so, it quickly “stat/check” the script, to know whether or not the source code has been updated by checking the “mtime”. Because we are talking disk I/O here (read access), we are therefore talking performance lost. While this makes sense with code source that frequently change, it is therefore a waste of resource on a webserver with less frequent code change.
Problem with apc.stat
Now the problem with apc.stat is that if you were to have a periodic rsync or svn merging of code source, APC will still reload the OPcode cache. Why? simply because tools such rsync/svn update the “mtime” of the file, even though there hasn’t been any code update. We can resolve the problem with “apc.stat_ctime“
This variable allows us to change the behavior of apc.stat by making APC check the number of inodes and not the mtime. That is to say, APC will only flash the OPcode cache if the source code has truly been modified.
That variable controls the time till the garbage collector kicks in. Because the OPcode cache can be access by many processes, it can only be cleared until all processes release the data. It can happen that a process dies without properly releasing the data and thus keeping the data into the cache. “apc.gc_ttl” will then trigger after the specified time, the garbage collector to force the clearing of the data cache.
There are more variables to consider when customizing APC, but those are in my opinion, the first to pay attention and start tweaking to fit your needs.
APC Management Page
As discussed in Part I, APC ships with a stack of API that allows you to check which OPcodes are cached, how frequent those OPcodes cache are accessed etc..
It is important to note, that the management page is vital to tweak and customize APC to fit your needs.
Copy the apc.php script in /usr/share/php/ (cf. APC-x.x.x.tgz) your webserver root directory
Edit the acp.php file and set authentication to true
then set your username and password
save and access http://hostname/acp.php