“Classic” PHP Caches in 2016
For a time, APC ruled the world, and it was good.Then, it’s development stalled, apps began to break, and PHP 5.5 support never materialized under pressure of Zend. So sadly, end of story here.
This is the current canonical solution, it comes bundled with every PHP since 5.5.
Zend knows a bit about PHP, no doubt. But its opcache is not really a one-size-fits-all solution, as APC. It usually comes up fastest in benchmarks, but at a price:
no clean up (once it gets full, it’s full and just waits for a complete waste purge or server reset)
The clean up thing becomes a problem when your complied php codebase is larger than the spare memory (rule of thumb 32MB per one average CMS). If you try to host even a small number of those, on a 2G VPS, it adds up quickly.
Zend OPCache never frees cache memory. Invalidation just marks space as “wasted” - lost for the rest of the server lifetime.
When you do run out, nothing catastrophic happens. The cache hit rate will start to drop slowly (tuning guides cite <99% as an indication of waste accumulation).
You can restart the server to clean the cache, but then it takes some time “warming up”.
The user caching can be outsourced by dedicated solutions, like memcached, apcu. Strangely there is currently no user caching available in PHP7 anywhere.
Other nice features include:
Read more, than you ever wanted to know about OPcache.
The rebels from lighttpd implemented op/variable caching in a way which makes it more flexible and it rocks. It’s supported on up to PHP 5.6 and is only marginally slower than Zend (rather in the “YMMV” area).
Significant features include:
User caching is a no-brainer. People and apps got to used to it.
Splitted cache was designed to leverage parallel memory access on SMP computers, but that is more of a theoretical advantage. It’s not even clear, if it offers any advantage in a common multi-core system. But let’s not dismiss this one...
Having TTL’d cache items is a nice feature, but comes with new problems. One of the most painful is memory fragmentation management.
When you start deleting chunks of memory, holes appear. Dealing with this is more difficult as it sounds and fragmentation was a problem in APC. Sooner or later you end up with holes which are not big enough for new data.
The cache has to do garbage collection, look for holes big enough for now data, it can start cleaning up by moving fresh things around, etc. It all comes at some CPU cycle price and disrupts the speed-up summary.
This is where that splittedcache makes a comeback. XCache allows you to manage/clean pools separately, so you can partially reclaim the space, without the need to flush it all out.
I’m not really sure how keys are split to caches, whether you can influence that, or that there is a automated mechanism for fragmentation resolution in XCache. But you can push the button and gradually clean the cache up.
Note that XCache supports PHP 5.1 - 5.6, but hasn’t been updated in 18 months and PHP7 probably isn’t going to happen.
When you can give enough memory to cache and have immutable source files in production, it doesn’t. You are better served with OPCache here most of the time.
When your can’t afford reserving space for seldom used items, when you run out of space, resets regularly on waste-limit, suffer from cache hit rate degradation, or high delete rates, it does. Consider XCache and it’s manageability.
This comparison assumes that you know the implications of different ways of serving PHP (fast/CGI, FPM, mod_php, LSAPI, etc) has on opcaching.
I couldn’t find any other opcache extensions for PHP 5.6
HHVM uses a different approach altogether and is not described here.
jacobvanloon
turnnoffyourmind
kianamaiart
janainaart
discoholicmusic
annaxmalina
titsay
origamiaround
