Add APCu support

A release for APCu will be made.

I've been running APCu with Drupal and the APC module for a few weeks, and everything works pretty well on account of APCu's near-perfect API compatibility. There are only a couple of slight modifications that needed to be made:

• When APCu is enabled, the keys for the array returned by apc_cache_info() are slightly different. This causes apc_requirements() to get a bit wonky: notices are thrown and update.php is unable to be run.
• APCu doesn't provide an opcode cache, so the option to clear it in Performance Settings is the same as clearing the user cache.

Attached is a patch that accounts for APCu in apc_requirements by populating the correct keys in $cache as well as checking for the correct version of APCu (the as-yet-unreleased 4.0.2, which fixes a bug that broke the BC layer). It also removes the opcode cache clear button from Performance settings.

I cannot get it working, even on a site which used APC object cache before the PHP 5.5. upgrade. I installed APCu 4.0.2, made sure it was loaded, and followed README.txt and enabled the module but according to apc.php there were no hits.

Incidentally the patch in #3 does not apply cleanly to current dev (or stable) version.

Just tested the patch again: applies cleanly to the 7.x-1.x branch:

$ git clone -b 7.x-1.x git@git.drupal.org:/project/apc.git && cd apc
Cloning into 'apc'...
remote: Counting objects: 133, done.
remote: Compressing objects: 100% (101/101), done.
remote: Total 133 (delta 71), reused 57 (delta 28)
Receiving objects: 100% (133/133), 32.30 KiB | 0 bytes/s, done.
Resolving deltas: 100% (71/71), done.
$ git apply -v ~/Downloads/apc-apcu_support-1984180-3.patch
Checking patch apc.install...
Checking patch apc.module...
Applied patch apc.install cleanly.
Applied patch apc.module cleanly.

There have been no commits to that branch since the patch was posted, so there'd be no chance it needed a reroll.

As of 4.0.2, APCu has a full backwards-compatibility layer with APC user cache—it provides the exact same functions—as long as you select it during installation (the option is enabled by default if you manually install the extension). The only place the APC will trip up is in the requirements checking, which is what the patch in #3 fixes. If you're not getting any hits to your user cache, there's a problem in your APCu setup. I'd check to see if you're able to add anything to the cache using the apc_* functions directly.

Sorry, patch does apply.

I reinstalled and tested my installation of APCu with a short apt_store and apt_fetch script and it works. However I am not seeing any hits in user cache in apc.php. As far as I can see the old version of apc.php packaged with APC 4.0.2 does not work with APCu, so I must just assume there are cache hits.

With the patch applied, you should see cache hits under the Status Report (admin/reporting/status): under APC it should say something like:

APC has been running for 9 hours 2 min. Currently caching 1661 entries (15.75 MB).

Alternatively, you should be able to check the status of APCu's cache by calling apc_cache_info(), which is the same function the APC module uses to create the status report.

Well, I'm not sure if this discussion points to the real important question, but
...installing apache php mysql and such the regular way on Ubuntu 13.04 or 13.10 will install Zen opcache and activate it by default. It simplifies the process of installing caches like this rapidly.

phpinfo() even shows a cache size mirror and Zen opcache replaces APC cache completely (won't work side by side) and as my life experiences tells me about how water goes down the hill, that also will cause that the mass of users will stop worrying about APC or APCu either more and more.

The question should rather be: does need Drupal some module support to work at its best and better with this future caching called Zen opcache, and if so, are the contributors of this module here willing to support this or do we need another initiative for that?

Zen opcache replaces APC cache completely

ZendOpcache/PHP 5.5's OPcache replaces APC's opcache, not its user cache. There is still a need for user cache, which is why APCu exists.

I've reset the title: a maintainer has indicated there will be an APCu-compatible release and this issue has a patch ready to review.

I took a look to see if APCu fixed the keys incompatibility, and it turns out it has, but it has not landed into a release yet. The patch in #3 will work for APCu 4.0.2, but the APC module should work without modification once APCu 4.0.3 lands.

Attached is a modified patch that omits the key name changes: what's left is the requirements message clarification and the removal of the clear opcache button.

Sorry, forgot to bump the version in the requirements message to 4.0.3.

I built apcu from git and it seems to work fine with apc-7.x-1.0-beta4.

I uploaded it to https://launchpad.net/~brianmercer/+archive/php5-apcu for ubuntu/debian users.

So, this is related, but not necessarily directed toward the module. I'm trying to find a copy of APCu 4.0.3, but I can't. Brian, I tried your repo, but, at least on my system, it calls your version 4.0.2, which means that when I apply the patch from #12, I can't enable it because it says I need 4.0.3. Looking through the pecl channels, only 4.0.2 is available. Is there something I can play with in order to make it work?

Also, here's a quirk: apc, for me, is set to off for cli, and so I can't enable the module with drush. Perhaps there could be a check to see if apc is enabled for fpm and enable it based on that, ignoring the cli configuration.

@sprice

You need to build from the GitHub repository to get the latest BC changes:

git clone -b master git@github.com:/krakjoe/apcu.git
cd apcu
phpize
./configure
make
sudo make install

Unfortunately, APCu's maintainer hasn't bumped the version in the code to 4.0.3, so it will still report as 4.0.2. He said a new release would be rolled "soon" about a month ago.

If you've applied the patch in #13, you can confirm it's working despite the requirements error if it reports non-zero values for the size of the cache and the number of entries. Alternatively, you could temporarily edit line 15 in apc.install to say 4.0.2 instead of 4.0.3. Unfortunately, the full release of APCu doesn't contain all the necessary BC fixes, so it's not a permanent solution.

Your issue with enabling the module with Drush is unrelated to the changes needed for APCu; I think this issue will help you resolve that: #1567440: Can't enable module using Drush

Yeah. I should have changed the version in the ppa to 4.03 git but I forgot. However, I don't think you need any patch from this thread which checks versions for this to work. I don't think I applied any patch, though I might be using the dev version.

If you're using the latest APCu from git, it should work without modification: you do not technically need a patch to the APC module to get going. The patch does two things:

• adds a check for 4.0.3 because the release version of APCu 4.0.2 does not contain all the necessary BC fixes
• removes the opcache clear button from the Performance settings page because APCu does not handle the opcache

adds a check for 4.0.3 because the release version of APCu 4.0.2 does not contain all the necessary BC fixes

Can you tell me why you bumped to 4.0.3 exactly? Ubuntu 13.10 comes with 4.0.1 so we would be excluding lots of users when we depend on a version no-one can install from official repositories.

4.0.1 broke the BC layer that allows APCu to function as a drop-in replacement for the APC extension (I pointed to the related APCu issue in my first comment). 4.0.2 fixed the BC layer, but array returned by APCu 4.0.2's apc_cache_info() was API-incompatible with APC 3.*:

• Returns the key nentries instead of the expected num_entries
• Returns the key stime instead of the expected start_time

The patch in #3 will allow the APC module to use APCu 4.0.2 by manually rewriting the keys.

However, the API incompatibility between APCu's apc_cache_info() and the APC extension's apc_cache_info() was fixed upstream. It should make it into APCu 4.0.3. The patch in #12 forgoes the manual key rewriting and relies on an eventual APCu 4.0.3 release.

Unfortunately, but the APCu maintainer has not yet rolled a new release. Since there's no timetable for APCu 4.0.3 other than "soon" and the patch in #3 works with 4.0.2, that is probably the better way to go until 4.0.3 is released.

It's unfortunate that Ubuntu decided to include APCu 4.0.1 even after 4.0.2 was released but it's not fit for purpose as a drop-in APC replacement. Currently, anyone should be able to upgrade to 4.0.2 by using PECL.

APCu has been released and the fix mentioned by @MarkTrapp in #19 merged: https://github.com/krakjoe/apcu/pull/42#issuecomment-26665923

This would mean that this patch will need further edits or a readme stating that the module requires ACPu 4.0.3 to work?

The current README points to the requirements page, so I don't think it requires editing. The patch in #12 should also work without modification, but I went ahead and mad a minor change to explicitly call phpversion('apcu') to be a little more future-proof.

Ubuntu 13.10 comes with 4.0.1 so we would be excluding lots of users when we depend on a version no-one can install from official repositories.

Just installed Ubuntu 14.04, which has php5-apcu 4.0.2, so even the latest version of Ubuntu doesn't support the APC module.

Isn't it possible to work around the differences in 4.0.1 and 4.0.2 instead of blacklisting them?

BTW, there's also a 4.0.4 available: http://pecl.php.net/package/APCu

Like I said in #19, support for 4.0.1 is not possible because it broke the BC layer, and 4.0.2 support is possible with the patch in #3: it includes a shim that fixes the incorrect apc_cache_info() keys that APCu 4.0.2 provides.

Here is a patch that combines #21 and the shim of #3.

I tried installing ACPu v4.0.4, but it's using the same incorrect apc_cache_info() keys that was supposedly fixed. Reverting back to the master branch (https://github.com/krakjoe/apcu/tree/master) which reports version v4.0.2, works with the patch in #11. Seems to be a messy situation with ACPu releasing versions that are mistagged, then containing regressions....

FYI, here's my post in github about the incompatibility for APCu versions 4.0.3 and 4.0.4:

https://github.com/krakjoe/apcu/issues/41#issuecomment-45391103

Hopefully it will be fixed soon.

4.0.6 has been released on APCu, for what it worth, however, I arrived to this issue looking to use opcache instead of APC and seeing if a simple approach was to be used. I realized this issue started with that question but then it moved into mainly APCu. I am a bit new to APC/opcache, can somebody help me understand what exactly the user cache is being used for, and what's the planning for when 5.5 are more widespread? I am on PHP 5.4 and I was hoping to use opcache, but didn't find an opcache module on drupal to replace this one, maybe converting this module to opcache is not that difficult, is that the plan? will opcache+APCu the next move for this module, or just APCu and then some other opcache module handler?

Anyway, any pointers, help and insights of what to expect will be appreciated. It seems that using just APC is still the way to go, at least the quickest, right?

Thanks!

@hanoii, this module does not deal with APC's opcache outside of providing a "clear opcache" button. If you only want to take advantage of an opcache and you have...

• PHP 5.5 installed, or
• APC installed with PHP<5.5,
• ZendOptimizerPlus/ZendOpCache installed with PHP<5.5, or
• any other opcache provider

...you do not need this module. You just need to follow the installation and configuration instructions for PHP 5.5's opcache, APC, or your opcache provider of choice and the opcache will be enabled automatically.

APC provides a user cache, essentially a key-value store, in addition to its opcache. That is what this module uses to provide an alternative to Drupal's database-based caching. The work in this thread is to provide support for APCu, which is intended to be a drop-in replacement for APC's user cache, but not its opcache. If you want to use APCu for a user cache, you still need a separate opcache.

Patch from #24 was missing the disabling of the reset opcache button and restricted the shim to 4.0.2, but it's still a problem even with 4.0.6.

Attached is a new patch:

• Reset opcache button is again disabled when running APCu
• Shim no longer checks for version, but for the errant keys
• Requirements checks are now aware of what extension is loaded
• Fallback requirements message when no APC module is enabled now points to APCu in addition to APC

@Mark Trapp thanks for the reply, it was extremely clear and to the point. It seems I missed the scope of the module. Is there an actual advantage of using APC for key-value storage as opposed to other mechanism, like memcached, redis, etc.?

For single-server setups, APC is easier to set up and, in some scenarios, faster than alternatives like Redis or Memcached. If you've already "graduated" to a more complex K-V store, or use multiple servers that need a shared cache, you probably aren't going to get much out of APC(u)'s user cache.

The BC fixes for APCu have finally landed in the correct branch, so they should show up in 4.0.7.

receiving a lot of errors like:
num_entries in apc_requirements() (line 18 of /mysite/sites/all/modules/apc/apc.install).
completely are gone after patching the -dev module with the patch form #29.
And before that the admin/reports/status site showed me that APC (i run APCu) was running since 44 years :). Now it shows that APCu !!! is running since 7 minutes.
So this patch is wonderful !
Thanks a lot!

Patch in 29 works for me.

Committed on dev
http://cgit.drupalcode.org/apc/log/?h=7.x-1.x

just to be sure: stable release does not work with APCU, is that right? I get incompatibility on PHP7.