Installing PHP APC on Ubuntu Dapper (and Debian?)

Update: this article is for Ubuntu Dapper Drake (6.06). If you are using later versions, or other Linux distributions, then visit the following links:

APC is a op-code cache for PHP that eliminates the parsing and compiling of script(s) for every page hit. Unlike Zend, it is truly free, and seems to have a lot of commuity momentum behind it lately.

As with all optimizations, there is a trade off. APC can use more memory on your server than without it.

The instructions below assumes that you have full control of your server, whether a physical dedicated server or a virtual private server.

Although one can always compile from source, this is more time consuming than using Debian's excellent apt-get.

Here is how I did it on two machines, with one more to go.

Getting the packages

First, we run apt-get to get what we need, if it is already not there.

apt-get update
apt-get install apache2-dev php5-dev php-pear make 

Preparing for pecl

I am using Apache2 and PHP5 on the development server. Adjust the versions above if necessary to match your environment.

Since I am using Apache2, the apxs is named differently, and pecl will fail if I do not work around this. So, I had to provide an apxs which is just a symbolic link.

ln -s /usr/bin/apxs2 /usr/bin/apxs

Running pecl

Next we use pecl to download, compile and install APC.

pecl install apc

My development server is now an AMD Athlon 64, using a 64-bit kernel. It had a strange problem running the above pecl command, with an error saying:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 143 bytes) in /usr/share/php/PEAR/PackageFile/v2.php on line 1772

The same Ubuntu version on my Pentium III test server does not have this error at all. It has the same Apache and PHP versions as well.

Others have encountered this problem, and the workaround as provided in this page, is to adjust the memory inside the script (it does not work in the php.ini).

Edit the /usr/share/php/pearcmd.php, and add:

@ini_set('memory_limit', '16M');


Now you can run the above pecl command once more.

Now, all you need to do is to add the following to the /etc/php5/apache2/php.ini file:

Now, restart Apache using:

/etc/init.d/apache2 restart 

Now you have a code cache that should speed up Drupal, and you can benefit.

To upgrade APC in the future, use the commands:

pecl upgrade apc

Followed by:

 /etc/init.d/apache2 restart

More info

APC is not the only op-code cache / accelerator.

You can read more in PHP op-code caches / accelerators Drupal big site study.

There is also a benchmark of APC and eAccelerator using Drupal.

Links and Resources



Thanks Khalid!

I've been considering installing a cache but was worried that it would be a difficult install and that I'd end up losing a day being a sysadmin instead of actually programming. So I've waited. But you lay it out so nice and easy, I think I'm now brave enough to give it a go.



You are welcome.

You are welcome. Ask for help if you need to. You have my email.

I have done it on two machines, with no ill effects so far, but they are development/testing.

I will be doing the same to the production server once I upgrade it to Dapper though.
Khalid Baheyeldin

my apache server down


Thank for this tutorial, it help me to setup APC in my server, after a day of runing APC my apache get down

sd1421:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.40GHz
stepping : 9
cpu MHz : 2423.881
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up cid xtpr
bogomips : 4852.44

sd1421:~# cat /proc/meminfo
MemTotal: 504920 kB
MemFree: 31168 kB
Buffers: 34592 kB
Cached: 129016 kB
SwapCached: 2312 kB
Active: 384296 kB
Inactive: 64368 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 504920 kB
LowFree: 31168 kB
SwapTotal: 512024 kB
SwapFree: 508856 kB
Dirty: 564 kB
Writeback: 0 kB
Mapped: 298348 kB
Slab: 19284 kB
CommitLimit: 764484 kB
Committed_AS: 522820 kB
PageTables: 1716 kB
VmallocTotal: 520184 kB
VmallocUsed: 3052 kB
VmallocChunk: 516852 kB

you can take a look at my php info

and what is you suggestion for my apache setting

sorry to write such a big comment and thanks for your great job to drupal community

small world

Matthew Carroll provided the outline for the procedure above.

My pleasure :-)

What a small world it is! I was just looking around to see if anyone had run into problems using APC with Drupal (Gallery 2 doesn't play nice).

Anyway, I'm glad the time I spent fumbling around with APC has been of use to a few people.

Good write-up

I'm about to install APC on a dedicated server running Debian (though using Lighttpd instead of Apache), so it's good to see that it looks like a straightforward procedure these days.

BTW, any particular reason to still use apt-get instead of its newer and better successor, aptitude?


Regarding apt-get vs. aptitude, it is just a matter of preference. They both do the same thing, but from a different interface. I am an old UNIX hand (almost 20 years now), so the command line is my preferred interface, not GUIs or TUIs (Text User interface).

As for lighttpd, I ran it on my test server for a while, and it basically works. Memory footprint is less than Apache, but there are a few rough edges (no mechanism for per directory/per user .htaccess equivalent). I reverted back to Apache. I plan to write the details of how to configure lighty for Drupal, since that part may be useful for others.
Khalid Baheyeldin


Wrong, buddy. I use aptitude strictly in CLI mode, never in its GUI. aptitude resolves inconsistencies much better than apt-get and gives you more options for how to handle it. Also, it will remove old, unneeded packages so you no longer have to run debfoster or other utils to clean your debian install. It's a very good thing! :)

apt-get does what I need

So far, apt-get does what I need. I never had an inconsistency that needed aptitude.

For package removed, I use --purge.

I am sure that aptitude has more features and such, but all I am saying is that I have not needed any of them so far.
Khalid Baheyeldin

Good tute, and yes, aptitude did help!

I just ran through this how-to, it's certainly easier than last time I did it.

BUT in the middle I got a problem with

Package apache2-dev is a virtual package provided by:
  apache2-threaded-dev 2.2.8-1ubuntu0.3
You should explicitly select one to install.
E: Package apache2-dev has no installation candidate

... Before descending into dependancy-hell trying to guess what I was going to have to do - I scanned the comments here and decided to see if aptitude really did 'handle inconsistencies better'
Whatta ya know? It DID!

It looked a bit scary ...

The following packages have unmet dependencies:
  apache2-threaded-dev: Depends: libaprutil1-dev but it is not installable
Resolving dependencies...
The following actions will resolve these dependencies:
Install the following packages:
libpq-dev [8.3.3-0ubuntu0.8.04 (hardy-updates)]
Downgrade the following packages:
libpq5 [8.3.3-1~gutsy1 (now) -> 8.3.3-0ubuntu0.8.04 (hardy-updates)]
Score is -71
Accept this solution? [Y/n/q/?] y

Downgrade? Oh, it's from the previous core version. I guess there may be a reason for that. No idea what pq5 is anyway.
So I crossed my fingers and let it run. And all is now sweet in Hardy-Heron.

Thanks to both of you!