Posted by tuoermin on Fri 11 Jan 2008 at 12:56
The Alternative PHP Cache (APC) is a free, open, and robust framework for caching and optimizing PHP intermediate code. It's an PECL extension which shares the packaging and distribution system with its sister, PEAR.
Provided that you have PEAR (php5-pear) package installed on your system, the procedure is as simple as pecl install apc. Alternatives.
meglohvat:# pecl install apc downloading APC-3.0.16.tgz ... Starting to download APC-3.0.16.tgz (114,298 bytes) .............done: 114,298 bytes 45 source files, building running: phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519 Use apxs to set compile flags (if using APC with Apache)? [yes] :
As probably corectly guessed by PECL package managers, you are runing an Apache web server so you should confirm by typing yes or hitting Enter key.
checking for re2c... no configure: WARNING: You will need re2c 0.9.11 or later if you want to \ regenerate PHP parsers.
The re2c package was missing on my system ›› apt-get install re2c.
checking for gawk... no checking for nawk... nawk checking if nawk is broken... no
I had no gawk or nawk but mawk pattern scanning and processing language installed on system ›› apt-get install gawk.
checking whether apc needs to get compiler flags from apxs... 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 /tmp/tmpJQuZdD/APC-3.0.16/configure: line 3846: apxs: command not found configure: error: Aborting ERROR: `/tmp/tmpJQuZdD/APC-3.0.16/configure --with-apxs' failed
Missing APache eXtenSion (APXS) tool for building and installing extension modules for the Apache HyperText Transfer Protocol (HTTP) server. APXS is found in apache2-threaded-dev package. The command apt-get install apache2-threaded-dev will also install a long chain of dependencies.
A good place to start is Alternative PHP Cache chapter in PHP manual. There it's written that the default configuration is sutable for most instalations, but they single out two settings: apc.shm_size and apc.stat.
If you change these settings or not, the next step is to move the /usr/share/php/apc.php script into your webserver path and access it with browser. It provides a detailed look at what is happening with your cache and, with GD enabled in PHP, also shows you graphs of the situation of your cache.
After checking if caching actualy works, you should point your eyes to the Cache full count value (on the left tables under File Cache Information). Tne number tells you how many times the cache filled up the allocated memory and had to be cleared of entries not accessed within number of seconds set up with apc.ttl setting. "You should configure your cache to minimize this number if not the resulting cache churn is going to hurt performance. You should either set more memory aside for APC, or use apc.filters to cache fewer scripts."*
[ Parent ]
[ Parent ]
[ Parent ]
i initiated using apc back when turk-mmcache was finally being written off as dead, eaccelerator was a licensing nightmare (as far as debian was concerned), and zend was/is closed source. i had to debug compilation issues with apc to get it to compile against apache2 on x86-64. i didn't feel my bug/patch was handled well by upstream, so i was prepared to go elsewhere when i migrated to etch.
i had heard of xcache and already seen it enter the debian archive here, so when i was preparing to migrate to etch i figured i would just backport it. originally there were both php4 & php5 packages, but the php4 package disappeared when php4 was dropped from unstable. doesn't really matter because it probably would have been just as easy to drop the php5 half of the build as it was to s/php5/php4/ the current source package. so over the holidays i migrated from sarge & apc to etch & xcache 1.2.1-3 (as that's what was in testing at that time).
anyways, in my admittedly crude benchmarking (though my approach was similar to what i saw published elsewhere) xcache was a little faster than apc, but it's not discernable during use (where both are ~4x faster than plain php). but, then again, based on the response to my previous apc bug report, <sarcasm>what do i know about benchmarking</sarcasm>.
[ Parent ]