hmmm . some caching layer can certainly help with bigger sites, but as of 5.4.1.1 this is less needed.

we had APC turned on for concrete5.org, then turned it off as we kept running into an APC bug where it would crash under a heavy load ( i know..)

Frz - Do you think you can elaborate on concrete5.org's problems with APC? I can only imagine I'm running into a similar issue - things running great and fast, all of a sudden server crashes and I can only guess its APC since that is the only customization to my otherwise very vanilla server.

I'm running 5.4.1.1 - so I'm also curious if APC is not recommended... I've never really seen an official comment on the topic.

It seems like APC is absolutely great for sites of a certain size. However when it starts doing more and more work, I think memory leaks in it take its toll, resulting in core dumps and requirement apache to be restarted.

We turned APC off on concrete5.org entirely, however I'm not totally sure whether this was absolutely necessary; there are two components to APC – the opcode caching, which compiles PHP and speeds up things like includes, code running, etc... and then there's actually using concrete5's cache with the underlying APC cache as its backend (to store concrete5's data objects like Pages, users, etc...) It's possible that you could enable APC on a large site just for opcode caching, get some significant performance benefit and lower memory usage for PHP, and not use it for concrete5's main caching.

That said, I've seen a number of places where people have reported the same thing; your site will be running fine, and all of a sudden you'll get white screens. Sometimes clearing you session cookies will fix this, because it's tied to a particular browsing session on the backend. If you look up the apache error log you'll see entries like "exit signal Segmentation fault" sometimes with a process ID. Most solutions around this just simply involve a log watcher script that looks for this entry, and restarts apache when it sees it. This seemed inelegant to us, so for the time being we're running without anything, and looking at other options for both opcode caching and concrete5 caching.

To summarize: APC fine for small to medium sites, probably fine if you don't mind a log watcher script. Potentially fine for large sites if you use some other mechanism than APC to cache your concrete5 objects (like memcached, Zend Engine, file based caching, etc...)

Somewhat related - Im hoping you can tell me if this would be considered normal behavior or not, but in order to test the effects of turning off APC on a larger site, I removed the line from site.php and in doing so the site immediately started creating thousands of the "zend_cache---internal-metadatas---d5f3c..." files in the the files/cache/ folder - so many so that it ultimately crashed the server. Is this just because I've had APC on for so long its trying to build up this huge cache all at once and its failing?

Thanks a lot for the response by the way - I have tested some smaller sites with and without APC and there definitely is a performance boost on those sites with APC. I think your right about it causing problems on larger sites - I'd almost rather loose a second of loading time to know that its not going to eventually crash on sites like those.

Hmm. Yeah the files are due to using the internal file cache... But even though it makes a ton of entries I've never had it crash the server. Zend cache does have an option for storing cache entries in sub directories rather than all in one directory... I wonder if that would help