[wp-hackers] opcode caching + page caching plugin

[Jeff Waugh]

On Mon, Jul 30, 2012 at 6:49 AM, Steve Taylor <steve at sltaylor.co.uk> wrote:

> I guess I just wondered what use is the opcode caching would be if
> you're mostly serving flat cache HTML? OK, you'll speed up that page
> cache refresh and admin access. But is that so important unless you
> have a very high traffic site?
>

Lots of shared hosting blogs get away without an opcode cache because their
hosts haven't figured out how to scale their APC memory allocation along
with the growth of their customer's files. So while lots of smaller blogs
get away without it, I would say that opcode caching is the #1 no-brainer,
easy-as-pie optimisation to make as soon as you have control of your web
server. :-)


> One of our developers is questioning the fact that we need to manually
> run a script every time we update code to refresh the APC cache. If
> we're not getting worthwhile gains from APC, is this extra step to
> remember worth it?
>

The only reason you'd "manually run a script every time you update code" is
if you set apc.stat=0, which is an extra optimisation you probably don't
need to bother with. Stick with the default and let APC do the checking for
you.

I feel like there's a lot of "how long is a piece of string" questions
> buried in all this. Or is having APC + page caching more of a
> no-brainer than I'm making out?


APC opcode caching: No-brainer. Only one thing to worry about: Making sure
there's enough shared memory allocated for your code.

APC object caching: Very nearly a no-brainer. Takes some load off your
database. Might cause occasional surprises*. Just a drop-in away once
you're using APC. Again, only one thing to worry about: Making sure there's
enough shared memory allocated for your opcode cache *and* user cache (how
APC describes its key/val storage).

Page caching: Greater margin for error, but lets you avoid PHP / WordPress
for the most part, if not entirely. Some implementations will even store in
APC, which means you have to make sure there's enough shared memory for...
you get the idea. :-) You get to route around PHP / WordPress for many
requests, but not all. For instance, most page cache implementations will
not serve from the cache if the request is from a logged in user
(regardless of whether they're using the admin section or their user role).

* Such as your blog still working after you've deleted your database. :-)