I had a weird experience a while back when implementing a cache for one of my sites. I figured I'd use APC's user cache because it's pretty fast. All was fine and the site seemed to work really fast. So next thing I did was try ab on it to see how fast it really was. Man did the performance drop. The whole server collapsed! I couldn't make a single request to the server.

The cache was for DB query data (surprise :-), so I took a look at show full processlist. It showed it was running queries multiple times that should not have been running at all. This seemed weird, to say the least.

Next, I took a look at APC's status with apc.php and saw my cache keys there like they should be. So again, I tried ab and refreshed the stats page. Now it displayed a completely different page than previously; some of the keys were missing. I tried refreshing, and again, the results changed.

Then it hit me. It must have something to do with the nature of FCGI because my ab tests would make Apache to spawn new FCGI processes to be able to handle concurrent requests (ab -c). It's pretty obvious: APC has it's own cache for every FCGI process. Not only for user cache but for opcodes as well. With opcodes this is not so bad but a user cache will take a lot of your memory if the same data is stored multiple times. It can also be really slow to setup cache entries for every process.

I didn't want to have data cached multiple times in memory so I switched to memcached. Memcached sends data over a TCP connection so it's a bit slower than APC user cache, but who cares.

Because I'm such a Solar fan-boy I'll tell you that Solar has cache adapters built-in for both APC and memcached. See the full list of cache adapters for Solar here.