You can also run a script to watch for PHP/APC segfaults and just restart the the cache.
I cannot imagine running PHP without an opcode cache, you are losing a speedup of 300% to 500%
In my experience, stable APC releases have been very stable, but beta APC can poop out pretty bad, even if the changelog doesn't indicate anything that might affect your application.
I've used stable APC + PHP + Apache releases to do some large things, so not sure why APC is an utter bomb in 2012.
My gut feeling tells me that your profiling is correct, however - any significant PHP application (that isn't written terribly inefficiently) will have its bottleneck in data access and not the parse/compile stage. There's very little point to speeding up by 250% a portion of your app that only accounts for 2% of execution time!
Maybe.
... wat
> I cannot imagine running PHP without an opcode cache, you are losing a speedup of 300% to 500%
That's just not what my profiling showed.
There is most certainly a serious load reduction when using an opcode cache. It's not just common sense, you easily find a dozen independent benchmarks on the web proving it.
Now if you had the opcode cache running incorrectly you might not see the improvement (ie. some people misconfigure it where the memory is not shared and persistant, and instead gets destroyed as php children are created/removed).
In terms of microbenchmarks, opcode caches look spectacular. In terms of the larger stack, given the way Wordpress works? Meh, a few percent.
It might be worth it for a big site to shave a few dozen servers off the bill. But the overhead imposed by flakiness is not worth my time.