Spent an hour or so today working on a PHP accelerator for a modified Scout Portal Toolkit application we run on one of the library’s Mac OS X servers. The CWIS version of the SPT software is a really useful and well-designed application but it’s not clear that much time has been spent on optimizing it for speed. Or, perhaps it’s been carefully hand tweaked but still lumbers along. It’s not painfully slow, but it does seem to take a couple of seconds to load a page and I decided that was at least a second too long (can it ever be too fast?).
I spent a few minutes looking over the source but quickly noticed that the initial “require†statements brought in many hundreds of lines of code and optimizing all that would take much more time and effort than I felt was justified (and besides, the application’s running and who knows what trouble I’d introduce).
Time for a different tack.
I recently spent some time with the MAMP package (Macintosh – Apache – MySQL – PHP) and noticed that they included the eAccelerator for PHP caching (if you’re not familiar MAMP you might want to take a look. It is an all-in-one package for quick and easy installation of all the software needed to do Apache/PHP/MySQL development on an Apple desktop or notebook. Yes, it’s a universal compilation). You can’t use MAMP on OS X Server so I went off in search of the eAccelerator software to add to my existing server’s Apache/PHP/Mysql setup. I wasn’t surprised to find that Mac OS X isn’t much discussed in this context (is it ever?) but thanks to MAMP, I knew it should work.
The software (source only) is at http://eaccelerator.net/
An hour later, I can report that eAccelerator works with the default Apache/PHP/MySQL setup on Tiger server but it does require a bit of tweaking to get running. Here are the highlights:
1. If not there already, install XCode (Developer Tools) on your server. The latest version (2.3) is available for download but you’ll have to join the Apple Developer Connection (it’s free). Another option is the 10.4 install disks but that copy of XCode is probably not the latest release.
2. Correct the information in this file if (like my 10.4.7 installation) it is incorrect:
/usr/include/php/main/php_version.h
The php_version.h on my server was misreporting the actual version of PHP installed. It should have loooked like this:
#define PHP_MAJOR_VERSION 4
#define PHP_MINOR_VERSION 3
#define PHP_RELEASE_VERSION 3
#define PHP_EXTRA_VERSION “”
#define PHP_VERSION “4.3.3”
3. Download the eAccelerator source, unzip/untar it and take a look at the README. It will suggest this sequence:
usr/bin/phpize
./configure \
– -enable-eaccelerator=shared \
– -with-php-config=/usr/bin/php-config \
make
make install
With OSX server, I found it would not compile correctly until I also added one more argument to the configure command:
– -with-eaccelerator-userid=70
or whatever the userID eaccelerator runs as (in most cases this should be the same as the “apache” user (e.g., www or 70)).
Once “make install” finishes, you have to do a bit of work to enable PHP to find and load the module.
3. Modify /etc/php.ini adding the line (assuming you have no other extensions already running):
extension_dir=”/usr/lib/php/extensions/no-debug-non-zts-20020429/”
the “make install” process will tell you where it put eaccelerator.so and you want to use that path in the “extension_dir” statement above.
and you will also want to add these lines to your php.ini file:
extension=â€eaccelerator.soâ€
eaccelerator.shm_size=â€16″
eaccelerator.cache_dir=â€/tmp/eacceleratorâ€
eaccelerator.enable=â€1″
eaccelerator.optimizer=â€1″
eaccelerator.check_mtime=â€1″
eaccelerator.debug=â€0″
eaccelerator.filter=—
eaccelerator.shm_max=â€0″
eaccelerator.shm_ttl=â€0″
eaccelerator.shm_prune_period=â€0″
eaccelerator.shm_only=â€0″
eaccelerator.compress=â€1″
eaccelerator.compress_level=â€9″
In my case, I turned compression off (eaccelerator.compress=”0″). When on, it compresses the data before putting it in the cache. I was looking to save time, not memory or disk space. Of course, I could be wrong about this. Perhaps compressing takes little CPU power and the smaller cache blocks can be read and decompressed in less time than it takes to read the larger, uncompressed versions. Will do a bit more research on this setting. You can get some documentation for these settings on the eAccelerator project site.
You have to create the directory for the cache (e.g., /tmp/eaccelerator) and make it world writeable:
mkdir /tmp/eaccelerator
chmod 0777 /tmp/eaccelerator
Then restart Apache. You should begin to see data written to your /tmp/eaccelerator directory.
What exactly does this eAccelerator module do? Without a cache in place, every time a PHP script runs the sourcecode must be scanned, compiled and then executed. Once installed, the eAccelerator cache grabs a copy of this compiled code the first time a page is scanned and compiled, then stores that object code in the cache for reuse. The next time the same script is called, it executes this cached/compiled copy instead, skipping the scan/compile step. Eliminating that redundant overhead speeds everything up.
In the coming days, now that I have eAccelerator working, I’m going to find a moment to do some benchmarking on performance with and without the cache. Not so much for this particular application but I have a few future projects for the CWIS platform and need to figure out what sort of performance I can squeeze from it. I’ll report those results here but my empirical observations this afternoon suggest that load times for pages from this application have been cut in half.