APC opcode cacheing is a straightforward way of improving the performance of your site. Every PHP file on disk must usually be read into memory, turned into "opcode", and then - potentially - run by a PHP process. Opcode caching means that the first two steps in this process need only ever happen once, considerably speeding up PHP's handling of each request.
However, depending on your setup, opcode caching is typically shared between your webserver's PHP processes, and not with the command-line PHP executable. That means it's difficult to run apc_clear_cache('opcode')
to clear those caches: it will only clear the CLI executable's caches: which are cleared at the end of the process, anyway. You could always restart your webserver; but that could cause problems for site visitors, and would probably increase the load on the server temporarily, which you should avoid if you can.
Here's a Drupal-based one-liner to help you clear the opcode caches of a Drupal website, from the command line on the server running it, and from within a directory in the Drupal codebase (any directory will do.) It works by detecting the site's code root, putting a temporary file in there, then calling that file over wget to clear the caches, before deleting the temporary file.
web_root=http://example.com/ drupal_root=`drush status | grep "Drupal root" | \ sed -e 's/.*://'`; apc_file=`tempfile -d $drupal_root -s .php`; \ echo "<?php apc_clear_cache('opcode');" > $apc_file; \ wget -O /dev/null $web_root`basename $apc_file`; rm $apc_file
You should change "example.com" to be the URL of your own site. Also, your server will need to be able to request web traffic from itself, on that domain: not all server/firewall configurations permit that.
Note also that (as I mention above) this only works this from within a Drupal codebase; otherwise it'll just get confused: for Drupal, outside of the codebase, you could probably write an alternative using Drush site aliases that would be runnable from any directory, if you were feeling ambitious; for non-Drupal sites, on the other hand, you probably want to change how $drupal_root
gets discovered. Something like:
web_root=http://example.com/ non_drupal_root=`some_other_command`; \ apc_file=`tempfile -d $non_drupal_root -s .php`; \ echo "<?php apc_clear_cache('opcode');" > $apc_file; \ wget -O /dev/null $web_root`basename $apc_file`; rm $apc_file
might work, but I understandably haven't tested it, as I don't know exactly what framework you're using!
Comments
David Sheldon (not verified)
Wed, 11/12/2013 - 08:36
Permalink
What problems could you be
What would this solve?
What problems could you be having that means that you need to clear the cache? Is it that the cache has become too large, does the cache get into a state where it doesn't notice files changing on disk.
jp.stacey
Sun, 22/12/2013 - 16:45
Permalink
The latter: the apc.stat
The latter: the apc.stat setting in php.ini tells APC whether or not to bother checking if a file has changed on disk. For a large framework, switching off file statting can provide a decent performance improvement, but it does mean that, if you change any PHP files, you'll need to clear the cache somehow.