APC or OPcache?

[sneakyimp]

I seem to recall that there should be considerable performance improvement gained when one's server caches the opcode generated from a php file because it spares your server from having to recompile each PHP script every single time that script is executed. If I'm not mistaken, PHP offers apc and OPcache to accomplish this. Doing a quick search using yum, I see that I might install either. Can anyone help me figure out which to install? I'm not especially motivated (or compensated) enough to concoct some kind of benchmarking test. Any help would be much appreciated.

FYI, the yum packages listed:

===================================================================== N/S matched: opcache =====================================================================
php-pecl-zendopcache.x86_64 : The Zend OPcache
php56u-opcache.x86_64 : The Zend OPcache
======================================================================= N/S matched: apc =======================================================================
apcupsd-gui.x86_64 : GUI interface for apcupsd
php-pecl-apcu.x86_64 : APC User Cache
apcu-panel.noarch : APCu control panel
apcu-panel56u.noarch : APCu control panel
apcupsd.x86_64 : APC UPS Power Control Daemon for Linux
apcupsd-cgi.x86_64 : Web interface for apcupsd
fence-agents-apc.x86_64 : Fence agent for APC devices
fence-agents-apc-snmp.x86_64 : Fence agent for APC devices (SNMP)
php-pecl-apcu-devel.x86_64 : APCu developer files (header)
php56u-pecl-apcu.x86_64 : APC User Cache
php56u-pecl-apcu-debuginfo.x86_64 : Debug information for package php56u-pecl-apcu
php56u-pecl-apcu-devel.x86_64 : APCu developer files (header)
capstats.x86_64 : A command-line tool collecting packet statistics
perl-Mail-IMAPClient.noarch : An IMAP Client API

[sneakyimp]

OK sincerely hoping for more information on this. I've been reading a variety of articles and confusing arguments but cannot seem to determine if I need to install OpCache or APC or whether my installation of php (5.6.6 on CentOS) already caches php code. I've tried checking defined functions and constants and there do not appear to be any related to either APC or OPCACHE. These all return no results:

php -r 'print_r(get_defined_functions());' | grep -i opcache
php -r 'print_r(get_defined_functions());' | grep -i apc
php -r 'print_r(get_defined_constants());' | grep -i opcache
php -r 'print_r(get_defined_constants());' | grep -i apc

[Weedpacket]

Never had to compare them myself, but I do note that OpCache is bundled with PHP while APC is third-party.

If either is installed and/or enabled, there will be a section in phpinfo() listing the configuration settings.

[sneakyimp]

Thanks for your response!

Weedpacket;11045723 wrote:

Never had to compare them myself, but I do note that OpCache is bundled with PHP while APC is third-party.

I'm confused on two points:
"OpCache is bundled with php" ? What does that mean? It certainly doesn't seem to mean 'definitely compiled in' because the word 'opcache' makes no appearance whatsoever in my phpinfo whether shown via CLI or apache.
"APC is third-party" - the term third party struck me as a bit odd in the PHP context. It's certainly a PECL extension but I have never stopped to think that the PHP dev's are any kind of coherent entity that could exclude some groups as not being party of the group. In fact, the PHP-DEV mailing list is quite a mess sometimes.

Weedpacket;11045723 wrote:

If either is installed and/or enabled, there will be a section in phpinfo() listing the configuration settings.

I see no such configuration settings in my php info and therefore wonder the best approach to getting it working. My distro (CentOS) has a coupld of packages that seem applicable and I'm guessing that might be the best way but then I was sort of wondering what 'bundled with PHP' means. I'm using 5.6.6 and see no sign of it. I could always try this:

sudo yum install php56u-opcache.x86_64

Also, I've heard rumors of zend_optimizer being incorporated but haven't seen anything definitive.

[Derokorian]

Definitive evidence that OpCache comes with PHP as of 5.5 -> http://php.net/manual/en/intro.opcache.php

APC is only supporting up to 5.4 http://pecl.php.net/package-changelog.php?package=APC&release=3.1.14

Additional info https://wiki.php.net/rfc/optimizerplus https://serverpilot.io/community/articles/how-to-install-php-apc-extension.html

[Weedpacket]

You could also ask: "If APC is the Alternative PHP Cache, what PHP cache is it the alternative to?"

[sneakyimp]

Derokorian;11045733 wrote:

Definitive evidence that OpCache comes with PHP as of 5.5 -> http://php.net/manual/en/intro.opcache.php

Unfortunately, this "definitive" evidence flies in the face of reality. I've got php 5.6.6 installed on this new server and phpinfo yields absolutely no hint of it. Additionally, the installation page contradicts that page:

PHP Documentation wrote:

PHP 5.5.0 and later

OPcache can only be compiled as a shared extension. If you have disabled the building of default extensions with --disable-all , you must compile PHP with the --enable-opcache option for OPcache to be available.

Once compiled, you can use the zend_extension configuration directive to load the OPcache extension into PHP. This can be done with zend_extension=/full/path/to/opcache.so on non-Windows platforms, and zend_extension=C:\path\to\php_opcache.dll on Windows.

I've also looked for ini settings related to OPcache but found nothing at all:

grep -i 'opcache' /etc/php.ini

I've also looked for any files like opcache.so which might indicate it exists on my server, but this returns nothing:

sudo find / -name 'opcache.*'

Derokorian;11045733 wrote:

APC is only supporting up to 5.4 http://pecl.php.net/package-changelog.php?package=APC&release=3.1.14

I see nothing on that page you linked that says "only up to 5.5" but I do see where they added support for 5.4 in release 3.1.10. It would seem like trying to install apc for my php 5.6.6 is a bad idea.

Derokorian;11045733 wrote:

Additional info https://wiki.php.net/rfc/optimizerplus https://serverpilot.io/community/articles/how-to-install-php-apc-extension.html

A lot of that looks pretty interesting, but I don't buy this on the second link:

Server Pilot wrote:

Both PHP 5.5 and PHP 5.6 have opcode caching built into PHP and it is enabled by default.

In fact, I think it's wrong.

[sneakyimp]

Weedpacket;11045735 wrote:

You could also ask: "If APC is the Alternative PHP Cache, what PHP cache is it the alternative to?"

A great question! Is APC an alternative to OpCache? or Zend Optimizer?

Also, APC is not an alternative for PHP 5.5 or 5.6, apparently as its only been updated to 5.4.

[sneakyimp]

Question posted to the PHP-internals mailing list

http://news.php.net/php.internals/84344

[sneakyimp]

Kind, clear responses from the PHP devs:

Rasmus Lerdorf wrote:

Opcache is bundled with PHP as of PHP 5.5, but distros like to unbundle
things and provide them as separate packages. We can't do much about
that and it is also hard to document all the variations distros come up
with. So yes, in your case you need to install the opcache package.
Presumably the way Centos has created the rpm it will add the
appropriate magic ini settings and you will see opcache listed in your
phpinfo() output after installing that package.

And ZendOptimizer is the same as Opcache in this context.

Rowan Collins wrote:

I think part of your confusion here is over terminology:

• Every module of PHP is referred to as an "extension", however deeply
  embedded it is in the language. The most basic functions you can think
  of, like string and array manipulation, are in "ext/standard" in the source.
• A module being "bundled" means that it is included in the official
  tarball releases on php.net, and indicates a certain guarantee of
  maintenance for compatibility with new versions of PHP.
• Some bundled extensions cannot be disabled, because to do so would
  break too many dependencies. Most can technically be disabled, and/or
  built as separate shared libraries to be enabled in your php.ini as
  desired. In the case of OpCache, it's bundled, but as a shared library.
• The PHP you install on a Linux system will most likely NOT be the
  official tarball, but something put together by your Linux distribution.
  They are under no obligation to handle all bundled extensions the same
  way, or enable them by default. They may for instance install the
  extensions as shared libraries and offer a script to enable/disable
  them, or they may put them all into separate packages which you have to
  install and then configure themselves automatically.
• Oh, and roughly speaking "OpCache" is the name for the open sourced
  version of "ZendOptimizer+", i.e. the version which was made available
  as a PECL download for PHP 5.2, 5.3, and 5.4, and included as a
  "bundled" extension in PHP 5.5 onwards.

This is all a rather long-winded way of saying the same thing Rasmus
just said, but maybe it will help. 🙂

So it sounds like although OPCache/Zend_Optimizer is "bundled" with PHP since 5.5, that does NOT mean that it has been installed in a given instance. With this information, I would feel pretty safe using yum to install php56u-opcache.x86_64. Unless I'm totally stupid, that would in fact install the latest OPCache/Zend_Optimizer using a package maintained by the CentOS team.

[Derokorian]

sneakyimp;11045749 wrote:

Unfortunately, this "definitive" evidence flies in the face of reality. I've got php 5.6.6 installed on this new server and phpinfo yields absolutely no hint of it. Additionally, the installation page contradicts that page:

php.net wrote:

OPcache can only be compiled as a shared extension. If you have disabled the building of default extensions with --disable-all , you must compile PHP with the --enable-opcache option for OPcache to be available.

This tells me that yes, it is enabled by default, unless using the --disable-all flag when configuring. This quote is from the installation page you linked to. The only thing I can think if you're install doesn't have it, is that you installed via a package manager that disables it.

sneakyimp;11045749 wrote:

I see nothing on that page you linked that says "only up to 5.5" but I do see where they added support for 5.4 in release 3.1.10. It would seem like trying to install apc for my php 5.6.6 is a bad idea.

They only updated to support 5.4, additionally it hasn't been updated since more than 9 months before 5.5's release. Also, the last stable version, was before they added support for 5.4, which are all listed as beta.

[Derokorian]

sneakyimp;11045767 wrote:

With this information, I would feel pretty safe using yum to install php56u-opcache.x86_64. Unless I'm totally stupid, that would in fact install the latest OPCache/Zend_Optimizer using a package maintained by the CentOS team.

And there it is, you're using yum. This is why I prefer building php from the tarballs on php.net.

[sneakyimp]

Derokorian;11045769 wrote:

This tells me that yes, it is enabled by default, unless using the --disable-all flag when configuring. This quote is from the installation page you linked to. The only thing I can think if you're install doesn't have it, is that you installed via a package manager that disables it.

Precisely what seems to have happened. One wonders about the wisdom of disabling it.

Derokorian;11045769 wrote:

They only updated to support 5.4, additionally it hasn't been updated since more than 9 months before 5.5's release. Also, the last stable version, was before they added support for 5.4, which are all listed as beta.

It would appear from what the devs told me that OPCache === ZendOptimizer and that these are preferred and are in fact the only option for 5.5 and 5.6.

Derokorian;11045769 wrote:

And there it is, you're using yum. This is why I prefer building php from the tarballs on php.net.

I've compiled from src before and find it quite a chore to work out all the dependencies sometimes. Additionally, I like that one can run yum update and yum upgrade and have one's packages updated quickly and promptly.

How has your experience been compiling from Scratch? Are you concerned about security patches and bug fixes? Do you have any processes to help manage updates?

[Derokorian]

sneakyimp;11045773 wrote:

I've compiled from src before and find it quite a chore to work out all the dependencies sometimes. Additionally, I like that one can run yum update and yum upgrade and have one's packages updated quickly and promptly.

How has your experience been compiling from Scratch? Are you concerned about security patches and bug fixes? Do you have any processes to help manage updates?

I don't know about you, but we have had many issues with updating through package managers, so at work we run our own packages for most things. As far as security patches and fixes, they can take months to get into package managers, but we get them the day they are released (well a few weeks later, after the new version has been vetted). In fact, our systems guys tend to hate using packages built by someone else due to security concerns!

For my personal projects, I have a standard build I use and keep it in a series of scripts, cut up version. I can run to build a new server out. This only works on CentOS but using variables for the version, I can change what version of things to install very quickly and simply. Basically I figured it out once, and just tweak it from there occasionally.

Within each of my repos, I keep standard things like php.ini, httpd.conf, etc so that I can have the same configuration easily.

[NogDog]

New project I'm working on at work is using HHVM as an approach to PHP optimization -- I know next to nothing about it right now, but at least my VM is working. 🙂 Oh, and it's running on NGNIX, just to add to my discomfort level. 🙂

[Derokorian]

NogDog;11045781 wrote:

New project I'm working on at work is using HHVM as an approach to PHP optimization -- I know next to nothing about it right now, but at least my VM is working. 🙂 Oh, and it's running on NGNIX, just to add to my discomfort level. 🙂

We have been trying to convert to HHVM for over a year, but it likes to SEG_FAULT purposely (aka the devs say its by design). Also, its been noticeably slower for us in the real world, enough so that its not a viable option at this time. However, for most projects, you'll see a significant improvement and access to Hack which is basically type sensitive php is pretty awesome.

[sneakyimp]

Derokorian;11045787 wrote:

We have been trying to convert to HHVM for over a year, but it likes to SEG_FAULT purposely (aka the devs say its by design). Also, its been noticeably slower for us in the real world, enough so that its not a viable option at this time. However, for most projects, you'll see a significant improvement and access to Hack which is basically type sensitive php is pretty awesome.

Oh man. Yet another thing to learn. I suppose I'll get right on that once I get around to AngularJS and Node.js. It stands to reason that a competitive software market will eventually automate all the things devs have traditionally gotten paid for, but my experience with these packages suggests to me that things are likely to break and nobody will understand why.