tags:

views:

254

answers:

7

The documentation on php.net is very spotty about causes of failure for APC writes. What kind of scenarios would cause a call to apc_store() to fail?

There's plenty of disk space available, and the failures are spotty. Sometimes the store operation will succeed and sometimes it'll fail.

+1  A: 

Out of disk space or permission denied to the storage directory?

Greg
apc_store() stores data in memory. Not on disk.
Frank Farmer
+1  A: 

In addition to what Greg said, I'd add that a configuration error could cause this.

Tom
+2  A: 

out of memory (allocated memory for apc, that is)

Nir Levy
+1  A: 

For php cli it needs to be enabled with another option: apc.enable_cli=On

In my situation it was working when running from a webbrowser, but not when executing the same stuff with php cli.

Kees van Dieren
+1  A: 

http://php.net/manual/en/apc.configuration.php

the apc.ttl and apc.user_ttl settings on php.ini:

Leaving this at zero means that APC's cache could potentially fill up with stale entries while newer entries won't be cached.

Angelbit
and in default are zero...
Angelbit
+1  A: 

this asinine (and closed, for some reason) bug was my problem:

http://pecl.php.net/bugs/bug.php?id=16814

has to roll back to apc version 3.1.2 to get apc to work. no fiddling with apc settings in php.ini helped (i'm on mac os 10.5, using apache 2, php 5.3).

for me, this test script showed 3 "trues" for 3.1.2 and true/false/true for 3.1.3p1

var_dump( apc_store('test', 'one') ); var_dump( apc_store('test', 'two') ); var_dump( apc_store('diff', 'thr') );

Paul
+1  A: 

apc_store will fail if that specific key already exists and you are trying to write again to it before the TTL expires. Therefore you can pretty much ignore the return false because it really did fail but the cache is still there. If you want to get around this, start using apc_add instead. http://php.net/manual/en/function.apc-add.php

ty91011