Complex PHP applications, such as Drupal, can gain a lot of performance benefits from running a PHP op-code cache/accelerators.
APC,
Alternate PHP Cache, is now the most maintained free/open source op-code cache, and is being used more and more as it emerges to be the
most stable.
The instructions here detail how to get APC running on a CentOS 5 server. The server happened to have Plesk on it as well, which initially made me hesitant to install APC "normally", since Plesk is so picky on what other software is installed on the server. However, it seems to have worked out well.
First, we need the pecl command so we can download and install APC from the repositories.
Do to so, we execute the following command:
yum install php-pear
But, this will not run on its own, we need the following package for the phpize command:
yum install php-devel
We also need the apxs command, which is installed via the following package:
yum install httpd-devel
Now we have all the software we need, so we install apc via the pecl command:
pecl install apc
Once that finishes, we need to enable apc in Apache's configuration. the following command should do this for us.
echo "extension=apc.so" > /etc/php.d/apc.ini
Then we restart Apache:
/etc/init.d/httpd start
And we are all done. Watch for less execution time per page, and decreased memory usage per Apache process compared to what you had
before.
Links
You can find some additional tips at Setting up Alternative PHP Caching APC support on Centos server.
Comments
Visitor (not verified)
Suggestion
Tue, 2008/03/25 - 05:24Nice and simple tutorial.
One question:
Why APC, and not eAccelerator?
In some of your previous articles (benchmarking APC vs eAccelerator using drupal and PHP op code caches/accelerators: a must for a large site) you wrote that eAccelerator has better performance over APC.
Khalid
Stability
Tue, 2008/03/25 - 10:50eAccelerator is definitely better than APC for speed (faster) and memory utilization (uses less memory).
However, with newer versions of PHP and Drupal, APC now has the edge in stability. Previously, we had maybe one or two seg faults with eAccelerator per week, which was acceptable, and the logwatcher script restarted things automatically.
After upgrading, it was seg faulting every 2 hours. Once we switched to APC, it was stable and rock solid.
There is also xcache, which we experimented with, but not used in production work.
I plan to publish updated benchmarks of APC, eAccelerator and xcache in the near future.
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
I have eAccelerator running.
Mon, 2010/11/01 - 05:48I have eAccelerator running. Will it conflit if I install APC too?
Khalid
APC for data cache or code?
Mon, 2010/11/01 - 10:37If you are using both as code cache, then it is not a good idea. They both do the same thing. See which one is more stable and use it and uninstall the other.
If you are using APC as a data cache, e.g. for cache router module, then consider using memcache, which is designed for this type of work.
In certain cases (e.g. Apache is mod_php, single server), APC is a good data cache. You can then configure APC not to act as a code cache and use eAccelerator instead, or use APC for both and have less components to configure and maintain.
Visitor (not verified)
Not found apc.php
Mon, 2013/01/21 - 09:53Hi all.
I have the problem that once installed APC on my server I can not monitor it because it can not find the file apc.php
Using Centos 6.3 and Magento 1.7.0.2, if someone has this happened and know where the file has been renamed or if you appreciate to help me, because I really do not know how far is working well.
The tutorial I followed is this: http://www.occentus.net/documentacion/item/instalacion-del-apc-cache-para-usuarios-de-plesk
and the file is not in / usr / share / php / apc.php
Greetings.
Visitor (not verified)
Thanks, Khalid. I asked my
Tue, 2008/03/25 - 09:57Thanks, Khalid.
I asked my host to do it for me and immediately from then onwards, all my drupal pages are showing an internal 500 server error.
Does APC have a problem with php running as suphp (like suexec)?
Thanks,
Venkat
Khalid
Doesn't work
Tue, 2008/03/25 - 10:44Actually I recall reading specifically that suexec is known not to work with APC. Perhaps this is because it is CGI (new process every time a request comes in). The only versions that work with APC and other accelerators are the mod_php (Apache) or Fast CGI.
In your case, suexec is a trade off (security vs. performance).
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
well, it seems to work:-) My
Tue, 2008/03/25 - 10:55well, it seems to work:-)
My host had simply given incorrect permissions on the temporary APC script. I don't know the intricacies of it, but they said setup would be slightly different on a cPanel VPS and enabled it.
Venkat
Khalid
suphp
Tue, 2008/03/25 - 11:20Thanks for the email.
Your site is running suphp (which is still CGI), and suhosin which some say is incompatible with op-code caches (not sure).
Please try with and without APC using devel and see if the pages execute faster with APC on suphp. I doubt they would.
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
Trouble
Thu, 2008/06/05 - 07:42The installing with your instructions goes just fine, but APC doesnt want to start for me. Apache / PHP gives the following error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/apc.so' - /usr/lib/php/modules/apc.so: cannot open shared object file: Permission denied in Unknown on line 0
Any help would really be appreciated
Pages