Looking ahead to PHP 5.5… Zend Optimizer & the end of APC

Have you done a bench test? Zend Optimizer has time and again not been proven any faster and APC is scheduled to be part of core PHP in the future.

Hi Fredrick, thanks for the response.

APC hasn’t had a stable release since May 2011 and 3.1.4 had to be pulled for a nasty bug. Development on it is slower than a WP site not running W3TC. And APC is even less compatible with PHP 5.5 than it is with 5.4 – I traced the source of my 500 errors to APC with PHP 5.4.

https://svn.php.net/viewvc/pecl/apc/trunk/?view=log

Thanks!
-J

That’s fine, Zend will not be supported.

Eh Frederick, seems you are a bit confused.

With the brand new PHP 5.5 branch, just released yesterday, Zend Optimizer+ is directly built in. This is pretty major, the first time an opcache has been a part of the core PHP package.

APC is actually discontinued (it will never support PHP 5.5), and will never be integrated into the PHP core. I think integrating APC was the plan years ago, but they decided to go with Zend Optimizer+ instead since it was open sourced and determined to be a much better choice.

I don’t know what went wrong with your benchmarks, but Zend Optimizer+ has been shown to consistently be a little bit faster than APC. The PHP developer team aren’t stupid, they chose Zend Optimizer+ for a reason.

https://wiki.php.net/rfc/optimizerplus
https://managewp.com/boost-wordpress-performance-zend-optimizer
https://halfelf.org/2013/trading-apc-for-zend/

To not support PHP 5.5/Zend Optimizer+ in W3CT would be a really weird and stupid decision. Sure, web hosts are incredibly slow in updating to the newest PHP versions, but deliberately not supporting an official feature of PHP 5.5 that can dramatically boost the performance of those lucky enough to have it, seems weird.

It seems everyone is confused here. Zend Optimizer+ is purely an opcode cache. It does not support the same features APC did that this plugin took advantage of. Once you move on to PHP 5.5 Zend Optimizer+ will work out of the box without any troubles. The only support this plugin needs is to make the clear opcache button work which would be executing accelerator_reset(). The userdata cache in APC will be gone though. This is supposed to be a drop in replacement for usercache, https://github.com/krakjoe/apcu#readme, but I don’t think it’s considered stable yet.

So in short he just needs to make the button work with it and we’ll have essentially full support. It will be up to the users if they want to grab APCu to continue using those features or switch over to an alternative opcache with usercache support, disk caching, or memcached (redis support would be neat though).

There is a heated debate here about Zend and APC. Everyone seams to understand it in their own way but perhaps this article will clear things up for all members https://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-benchmarks-with-symfony2/.
Things that you will find here also include a graphic representation of features. Also take a look at this post about Zend https://www.techyv.com/questions/zend-frame-work-last-version-auto-update.

APC is actually discontinued (it will never support PHP 5.5)

Here’s a screenshot of APC working with PvP 5.5.

I arrived to this thread after facing a lot of problems with this opcache.

Initially when I installed PHP-FPM 5.5 on my server, the wordpress admin panel was very fast (I didn’t know it was the work of opcache) and I was very happy.

But I was facing strange problems whenever I saved settings or posts. I had to submit it twice for the changes to be saved. First I thought it was due to APCu (yes as dfumagalli rightfully said APC is available via dotdeb repository. I installed it using “apt-get install php5-apcu“) and checked the apc.stat setting (if this is set to 0 similar problems will occur) but it was set to 1 only.

Then I thought it was something related to nginx but that too wasn’t the case. Then after checking “modules loaded” by PHP I found it was due to opcache.

So I disabled it only in the admin pages by adding the following code to “functions.php”

if(is_admin()):
ini_set("opcache.enable","0");
endif;

That solved the WordPress problem but I also had phpMyadmin installed. It started halting abruptly during delete queries.

I sometimes had to double check through the mysql command-line if data was in fact deleted. So now I have commented out opcache.so module from loading and everything is back to normal.

After all W3TC creates static pages so I don’t need opcache ??

Making Nginx + PHP (FPM) + APC work well is more of an art than technical skill. When you add memcached / redis and varnish and maybe a varying amount of available system memory, it gets even funnier.

In particular, both NGinx and APC come with very conservative if not downright bad default settings. It’s important to give APC and memcached enough room. The last (Xen) VPS I prepared, has Nginx in high availability configuration + PHP FPM + APC + memcached + varnish + MySQL 5.6 (in a master-slave setup) and it runs ISPConfig3, WP 3.6 with W3TC, a wiki and Magento 1.7 + another famous e-commerce software I am not authorized to disclose + phpmyadmin + awstats + squirrel mail and more. It works like a charm, including in the admins.
Therefore if my configuration works, then yours should too.
If it does not, I’d check the amount of memory given to APC as it seems to struggle dealing with demanding tasks like phpmyadmin and WP admin are. There is also a strong case for checking Nginx parameters as they command over PHP’s ones and Nginx comes with absolutely insufficient defaults for enhanced, large web apps.

hello,

I have had the chance to test php-fpm 5.5 with it’s new opcache and w3tc. All works fine but the opcache makes trouble as it caches the w3tc settings php files. Thus changes via the admin tool are not immediately visible which leads to confusion. Double saves and in my eyes sometimes even malfunctions. As opcache surely will be used more and more it might be good to use tweak your code to add opcache_invalidate(…) [https://www.php.net/manual/en/ref.opcache.php] for the affected scripts to make sure that the files are loaded new once the setting page’s confirmation page is rendered.

Many thanks for your work!

For those who still want to augment PHP 5.5 it’s possible to install APCu.
It’s a special version of APC that removed what’s in common with the latest PHP internal cache (so, no conflicts) while keeping the features the PHP internal cache does not provide.

+1 for APCu that stands for APC user cache. More info is available at https://github.com/krakjoe/apcu .

@jesin A if you modify your OPCache configuration as follows you will see that it will work better.

opcache.revalidate_freq=0
opcache.consistency_checks=1

I had yesterday the same problems with W3TC not saving files due to cache and I needed to do a “hard reset” of the browser to see the changes.
Please confirm if its working.

Thanks

@alexblajan I guess those settings slow down caching performance.

From https://www.php.net/manual/en/opcache.configuration.php

opcache.revalidate_freq integer

How often to check script timestamps for updates, in seconds. 0 will result in OPcache checking for updates on every request.

Now this means Opcache will check the script each time a request is made.

opcache.consistency_checks integer

If non-zero, OPcache will verify the cache checksum every N requests, where N is the value of this configuration directive. This should only be enabled when debugging, as it will impair performance.

@Jessin A well, its true but works for me. At the moment if I put those settings to normal, I have the same problem. Even if I want to save the W3TC settings.
I noticed that sometimes curl and opcache have some problems.