Feb 13 update! Zend Optimizer+ is now officially open source so these instructions to manually install the binary are no longer needed! Go here instead: https://github.com/zend-dev/ZendOptimizerPlus/
I’ve also written a control panel for it which you can find here:
With Zend supposedly open-sourcing their Optimizer+ opcode cache for PHP, likely replacing APC, I want to preview what I might be dealing with and any limitations/advantages.
However I did not want to install a bunch of unknown zend stuff into php slowing it down or causing conflicts, I only wanted the bare minimum and know exactly what I am installing.
Turns out it’s rather easy once you know what to look for.
As PHP internals explores replacing the APC opcode cache with an open-sourced Zend Optimizer Plus an interesting benchmark was published. It shows WordPress serving nearly 10% more pages per second than APC while using Optimizer+ (both under PHP 5.5).
Following a series of memory leaks and other problems, the 3.1.14 beta release of the APC opcode cache for PHP has been recalled and removed from the pecl site by Rasmus as it’s not currently suitable for use.
I noticed the memory problem a week or two ago. I’ve carefully tested each revision in the trunk after the 3.1.13 release and have found revision 328264 to be the last good update if you want some of the subtle bug fixes since 3.1.13 without the later problems.
You can fetch a specific revision via svn like so:
svn co -r 328264 http://svn.php.net/repository/pecl/apc/trunk/
This was the changelog for 3.1.14 which has been since removed: (more…)
There has been a growing discussion about this in PHP internals but now there is a semi-official wiki page explaining what is going to happen with the replacement of APC by Zend open-sourcing their OptimizerPlus opcode cache.
Right now it’s only a “proposal” but if you look at the internals discussion, it’s almost certainly going to happen, it’s just a matter of “when” not “if”.
Given that the few people working on APC would mostly likely stop and focus instead on Optimizer+, APC is now in theory, doomed. Which is a bit crazy considering how much code is out there to take advantage of it’s user cache (which is significantly faster than say memcached on a local single server). OptimizerPlus has no user-cache shared memory support at all, it’s only an opcode cache.
Not sure why the benchmark uses “ancient” WordPress 2.1.1 but in theory this would give even the newest WordPress 3.5 a five to ten percent performance boost.
PHP 5.5.0 will reach a feature freeze is on February 7th, 2013, just two weeks away, for it’s first beta release.
There was some discussion of including the APC opcode cache into 5.5 but this will decidedly NOT happen because it would delay release by several months.
However in an interesting twist, there is now discussion of open-sourcing ZEND OPTIMIZER PLUS and including with PHP 5.5 instead.
Zend Optimizer+ is a commercial opcode cache for PHP and is slightly faster than APC but currently used on only a small percentage of servers compared to APC.
This essentially would doom APC, despite the suggestion it would remain available as there are only a few contributors to APC at this time and then would obviously switch to the zend optimizer+ sooner or later.
Remember, PHP 5.3 will reach end-of-life in March with the release of PHP 5.5.0
I’ve recently had to abandon using eaccelerator because they are just not keeping up anymore with PHP releases and they even removed variable data cache support just to get PHP 5.3 compatibility. It’s sad because they were the fastest and most stable for years.
So I have been testing xcache and APC instead.
One trick I use on large/active servers for an additional performance boost is to turn off the file stat feature on the PHP opcode cache. This makes it stop checking the timestamp on each and every PHP file executed. WordPress for example has over 100 php files totaling nearly 3 megabytes on a typical install.
You’d use ONE of these directives in php.ini depending which opcode cache you use: