APC Settings: stat and shm_size

APC Settings: stat and shm_size

Most of you already know that APC is really important to boost PHP performance. It will probably be replaced in the next months / years by Zend Optimizer+ but meanwhile it is important to know how to properly tweak this amazing PHP extension.

If we have a look at http://php.net/manual/en/apc.configuration.php we will see in the first couple of lines that both stat and shm_size are the most important directives but most people seem to not know about them, and this is why I am writing this post. Yes, most sysadmins don’t even know that these settings exist and the big difference you can make playing with them.

  • shm_size: This is about how much memory will be reserved for APC. Please take into account that this memory is occupied both by your userland variables and by the opcode cache. So, the more PHP files your application has, the more memory you need. Thanks God, well thanks Rasmus, there is a PHP script to inspect how much memory we are actually using. You can grab it at http://svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup. And of course, in modern big PHP applications, with lots of libraries, dependencies, frameworks, etc.. it should be set at least at 64M and probably at 128M. Just inspect it in your production servers and you will find the most appropiate value.
  • stat: This setting is a really cool one. By default, every time we require a file in PHP, if it is stored in APC, it looks at the filesystem stat to see if the file has changed to load a new version in memory. Of course, this is really inefficient and it is much better to set apc.stat to Off. This way you can literally rm your application folder and all files cached in APC will still work! Of course, this also helps doing deploys even in big traffic moments. The only drawback is that you need to wipe APC (via Apache reload or similar) after every deploy so that the new code actually is installed. But the benefits are far more interesting that this minor drawback! And I honestly hope you are no longer editing remote files with Vim to quick fix Friday afternoon bugs 🙂

So, quite a short post, but I think it is worth it, provided there are already quite a bunch of companies where I had to fix this!