1. Opcode cache

It is especially useful, if not mandatory, to have an opcode cache available on a high traffic site. This mechanism permits to save the time for code analysis while loading a script, by using the result yet stored in cache. We typically save up to 80% of execution time..

1.1. eAccelerator

Site : http://eaccelerator.net/

This ancient cache, which was functional up to PHP 5.3, is definitely dead.

1.2. XCache

Site : http://xcache.lighttpd.net/

This was a proven solution, functional up to PHP 5.4.

Unfortunately, no activity seems to indicate a potential support of PHP 5.5 in a near future.

Packages : php-xcache, xcache-admin

1.3. APC

Site : http://pecl.php.net/package/APC

This PECL extension, managed by some of the PHP project developpers, was long considered as the cache of reference, promised for integration to PHP itself.

Unfortunately, PHP 5.4 support was never complete and its current version 3.1.13 is still in "beta" (version 3.1.14 was even withdrawn).

This project made the choice to provide several functionalities being unrelated to each other (opcode cache, user data cache and upload progress management), which is certainly a mistake.

It is therefore time to treat this extension as legacy and consider alternatives.

Packages : php-pecl-apc, php-pecl-apc-devel, apc-panel

1.4. Zend OPCache

Site : http://pecl.php.net/package/ZendOpcache

This is the proprietary extension (Zend Optimiser+) which source code was made OpenSource (under PHP Licence). It is available on PECL for PHP up to version 5.4 and is integrated in PHP 5.5.

Clearly, this is the solution with a future, which it is urgent to test while waiting for a stable, official release.

Packages : php-pecl-zendopcache (php 5.4) or php-opcache (php 5.5)

2. User data cache

Many applications need to store some data in cache to save their computation at each execution.

Here I will not mention network caches (permitting data sharing across several machines) like memcached, redis or other NoSQL servers, even thou they are very useful, in particular for session storage -- but only memory caches, simpler, permitting to manage persistence across several queries to the same server.

2.1. XCache

Site : http://xcache.lighttpd.net/

Functions : xcache_set, xcache_get, ...

Here again, it is sad to mix matters by associating 2 cache types. Let's hope however the project will be able to quickly provide a PHP 5.5 compatible release.

2.2. APC

Site : http://pecl.php.net/package/APC

Functions : apc_store, apc_fetch, ...

In the development branch (3.1.5dev), an option was introduced to disable the opcode cache (apc.enable_opcode_cache=0), which permits to use Zend OPcache and APC strictly for user data.

Packages : php-pecl-apc, apc-admin

2.3. APCu

Site : http://pecl.php.net/package/APCu

Functions : same API as APC.

This is a (friendly) fork of APC, dedicated to clean-up code from all the cache side of opcode and to provide an alternative permitting to supersede APC in a transparent manner to applications.

RPM are already available in the repository and you may start testing this extension. My expectations are high. To be followed...

Packages : php-pecl-apcu, apcu-panel

2.4. Yet Another Cache

Site : https://github.com/laruence/yac

Methods : Yac::set, Yac::get, ...

A new project initiated by one of the PHP language developers. An object API and a new design aiming at higher performance

RPM are already available in the repository and you may start testing this promising extension.

Packages : php-yac

3. Conclusion

As yet nothing is well stable for PHP 5.5. I hope we'll see things clarifying quickly, prior to final release.

Personally, I believe the right choice will be PHP 5.5 + Zend OPcache + APCu (for existing applications) + Yac (for new developments).

 

P.S. Thanks to Xavier Hourcade for the translation.