This tip isn't unique to Drupal, but rather applies to PHP in general using APC. For those who don't know already, APC or "Alternative PHP Cache" is a must have when running php sites. But how you can run APC varies. You can optimize APC for performance, but lose some flexibility, especially for a site in active development. Configuration for APC is usually done in an apc.ini file that is included automatically by the default php.ini, but you can also include this configuration directly in the php.ini itself.
There are great resources already on the web for learning the in's and out's of APC setup. Here are a few...
- http://xerosphere.net/optimizing-apc-for-drupal
- http://drupal.stackexchange.com/questions/12534/best-apc-settings-to-reduce-page-execution-time
In short the apc.stat property indicates whether APC should check a php file to see if it's been modified recently every time a request is made. As you can imagine, this adds a bit of overhead, BUT setting this value to 1 (true) is pretty standard. This is because chaos can ensue if you update the PHP code, and APC is completely unaware. Though because there is a big advantage for turning this option of 0 (false) I prefer to do so on live sites that are no longer in active development.
I can't discuss the apc.stat variable without also mentioning apc.ttl or "time to live". This determines in seconds how long a cache entry will remain before it expires. Setting this value to 0 will completely disable this check and keep "compiled" php in cache indefinitely. This is another big win for performance, but like stat is capable of causing issues. Unlike stat, in my opinion there is less need to completely disable ttl. Setting this value to a large amount... like a day is probably more reasonable.
Here is an example apc configuration file I have for a live site.
extension=apc.so
apc.enabled = 1
apc.shm_size=256
apc.shm_segments = 1
apc.stat = 0
apc.ttl=0
apc.user_ttl=7200
apc.gc_ttl=3600
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
Mixing with Drupal Features
While its part of a basic understanding of how APC works, it is easy to forget that if you have stat turned off the APC cache needs to be flushed. What is even easier for me to forget is that Drupal 7 and below have features stored as PHP. This means if a feature is updated, and the APC cache isn't cleared you will get some really strange results. (In Drupal 8, much if this kind of setup will be moved to configuration files rather than PHP code) A common symptom of this issue is seeing a feature in a "rebuilding" status (normally 'default', 'needs review', or 'overridden').
APC can be flushed a number of ways, but I would suggest either restarting Apache (gracefully)
/etc/init.d/apache2 graceful
Note: the apache control script differs in name depending on what Linux distro you are using. Alternatives are apache2ctl, service apache2, and httpd.
or installing the the handy APC Admin module that allows you to clear APC with the press of a button within the performance admin/configuration.
Need a fresh perspective on a tough project?
Let’s talk about how RDG can help.