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.

Articles

Comments

Khalid

Wed, 2010/07/14 - 10:39

You are making too much noise without substance.

Double check your facts before making accusations that make you look like a fool in public!

I just checked the above instruction on a pristine CentOS 5.4.

The /etc/php.d/apc.ini file does not exist after pecl installs apc.

# ls -l /etc/php.d
total 4
-rw-r--r-- 1 root root 51 Mar 31 02:51 dbase.ini

Now, we create the file using the instructions I provided:

# echo "extension=apc.so" > /etc/php.d/apc.ini

And now it exists where it has not before:

# ls -l /etc/php.d
total 8
-rw-r--r-- 1 root root 17 Jul 14 10:29 apc.ini
-rw-r--r-- 1 root root 51 Mar 31 02:51 dbase.ini

Learn the difference between /etc/php.ini and /etc/php.d/apc.ini. Perhaps this is lesson will be of some benefit to you.

Visitor (not verified)

Wed, 2010/07/14 - 21:29

I still maintain that it'll overwrite the file if it exists. And yes, I will admit that I got the php.ini and apc.ini files mixed up. Seems to me the better place to include the extension is in the php.ini file, which is where all the other extensions are defined anyway. I believe some of the other install tutorials I found didn't mention the apc.ini file at all and edited the php.ini directly.

So, my error, no big deal. :)

Khalid

Wed, 2010/07/14 - 21:39

Yes, any file that a > is used for will be overwritten. That is standard UNIX shell behavior. No one has debated that.

As for php.ini being a better place, you are wrong again. The whole idea of separating out the configurations into small extension specific files is that they can cleanly be created when an extension is installed and removed when it is uninstalled, without affecting other extensions.

Most distro now do it that way, instead of having one monolithic file that needs to be parsed and edited when an extension is added or removed.

Here is an example from an Ubuntu (Debian derivative) with a few extensions enabled in PHP (they go to /etc/php5/conf.d instead of /etc/php.d, but the same underlying idea).

-rw-r--r-- 1 root root  33 Aug 24  2008 apc.ini
-rw-r--r-- 1 root root  50 Jul  3  2008 gd.ini
-rw-r--r-- 1 root root  75 Sep 26  2009 local.ini
-rw-r--r-- 1 root root  56 Jul  3  2008 mysql.ini
-rw-r--r-- 1 root root  57 Jul  3  2008 mysqli.ini
-rw-r--r-- 1 root root  52 Jul  3  2008 pdo.ini
-rw-r--r-- 1 root root  60 Jul  3  2008 pdo_mysql.ini
-rw-r--r-- 1 root root 804 Aug  8  2009 xdebug.ini

Yeah, no big deal, hence the combative tone of your original comment was unwarranted.

Visitor zoka (not verified)

Sun, 2010/10/10 - 19:38

That file do not exist it is not appending things to php.ini it is creating new file with contest that echo outputs

Visitor (not verified)

Mon, 2010/09/27 - 15:12

I received the following error when trying the documented steps above:

/var/tmp/APC/php_apc.c:959: error: duplicate 'static'
make: *** [php_apc.lo] Error 1
ERROR: `make' failed

I tried installing apc-beta, but got the following error:

/bin/sh /var/tmp/pear-build-root/APC-3.1.4/libtool --mode=compile cc  -I. -I/var/tmp/APC -DPHP_ATOM_INC -I/var/tmp/pear-build-root/APC-3.1.4/include -I/var/tmp/pear-build-root/APC-3.1.4/main -I/var/tmp/APC -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib  -DHAVE_CONFIG_H  -g -O2   -c /var/tmp/APC/apc.c -o apc.lo
libtool: compile:  cc -I. -I/var/tmp/APC -DPHP_ATOM_INC -I/var/tmp/pear-build-root/APC-3.1.4/include -I/var/tmp/pear-build-root/APC-3.1.4/main -I/var/tmp/APC -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /var/tmp/APC/apc.c  -fPIC -DPIC -o .libs/apc.o
In file included from /var/tmp/APC/apc.c:44:
/usr/include/php/ext/pcre/php_pcre.h:29:18: error: pcre.h: No such file or directory
In file included from /var/tmp/APC/apc.c:44:
/usr/include/php/ext/pcre/php_pcre.h:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/php/ext/pcre/php_pcre.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/php/ext/pcre/php_pcre.h:44: error: expected specifier-qualifier-list before 'pcre'
/var/tmp/APC/apc.c:356: error: expected specifier-qualifier-list before 'pcre'
/var/tmp/APC/apc.c: In function 'apc_regex_compile_array':
/var/tmp/APC/apc.c:417: error: 'apc_regex' has no member named 'preg'
/var/tmp/APC/apc.c:417: error: 'apc_regex' has no member named 'preg'
/var/tmp/APC/apc.c:418: error: 'apc_regex' has no member named 'nreg'
/var/tmp/APC/apc.c:418: error: 'apc_regex' has no member named 'nreg'
/var/tmp/APC/apc.c: In function 'apc_regex_match_array':
/var/tmp/APC/apc.c:450: error: 'apc_regex' has no member named 'preg'
/var/tmp/APC/apc.c:450: error: 'apc_regex' has no member named 'preg'
/var/tmp/APC/apc.c:451: error: 'apc_regex' has no member named 'nreg'
/var/tmp/APC/apc.c:451: error: 'apc_regex' has no member named 'nreg'
make: *** [apc.lo] Error 1
ERROR: `make' failed

After a little googling I found the solution:

yum install pcre-devel
pecl install apc-beta

Hope this helps

Visitor (not verified)

Mon, 2011/09/26 - 01:00

I was on this page and looking for solution... but I was blinded to see this post... so dumb! After one hour and a lot of trail and error I finally have found the same solution you post here!

Visitor (not verified)

Fri, 2010/11/12 - 06:35

we have install pac

we have following step
1)yum install php-pear php-devel httpd-devel

2)pecl install apc

Then facing this problem:

Sorry, I was not able to successfully run APXS. Possible reasons:

1. Perl is not installed;
2. Apache was not compiled with DSO support (--enable-module=so);
3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs
The output of apxs follows
/var/tmp/APC/configure: line 3457: apxs: command not found
configure: error: Aborting
ERROR: `/var/tmp/APC/configure --with-apxs' failed

J Guesclin (not verified)

Thu, 2010/12/02 - 03:31

Assuming that all the installation runs ok and you manage to restart Apache, is there some simple way of verifying that it is working other than just empirically noting page load times?
Also, how do you go about uninstalling if it doesn't work?
Otherwise, many thanks for a useful (and easy to read!) tutorial.

Khalid

Thu, 2010/12/02 - 09:31

There are several things that you can do to verify that APC is working.

1. Check the output of phpinfo(). There should be an APC section there with the parameters it is using.

2. Search /usr/share for a script called apc.php. Run it, and you will see hit rate, memory usage, fragmentation, ...etc.

While performance varies depending on site complexity, the minimum improvement is that you should feel that most pages are at least 200 milliseconds less.

Pages

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting