APCu is the user cache left over once OPcache takes the opcodes

APC did two unrelated jobs: it cached compiled opcodes, and it offered a shared-memory key/value store to application code. PHP 5.5 bundles Zend OPcache and takes the first job away, and APC has no stable build for 5.5 at all — so an application calling apc_store() for anything needs somewhere for the other half to live.

// APCu 4 keeps the apc_* function names, so this code does not change
$rates = apc_fetch('vat_rates', $found);

if (!$found) {
    $rates = $this->loadVatRates();
    apc_store('vat_rates', $rates, 3600);
}

/*  php.ini — two extensions now, one job each

    zend_extension = opcache.so
    opcache.memory_consumption    = 128
    opcache.max_accelerated_files = 10000

    extension       = apcu.so
    apc.shm_size    = 64M
    apc.enable_cli  = 0
*/

APCu is APC with the opcode cache removed, and version 4 keeps the old function names, so the migration is a package change and an ini edit rather than a code change. Two things are worth knowing before treating it as a cache. It is per server and per SAPI — the CLI process gets its own segment, so a cron job priming the cache primes nothing any web request will see, which is why apc.enable_cli should stay off rather than being switched on to make a script appear to work. And there is no eviction policy worth the name: when the segment fills, APCu clears large parts of it at once, so the hit rate falls off a cliff instead of degrading. Size apc.shm_size from what is actually stored, and keep anything that has to be shared between servers in Redis.