[wp-hackers] Caching as part of the core
Otto
otto at ottodestruct.com
Thu Jul 19 16:57:04 UTC 2012
Caching comes in multiple flavors, you can't discuss it properly
without separating the concepts.
1. Page caching. This would be something like WP Super-Cache which
does static caching of the whole HTML page, thus eliminating vast
amounts of CPU execution on some sites.
2. Persistent object caching. This would be anything which hooks the
WP Object Cache and stores it somewhere. W3 Total Cache has this,
among other things.
Neither of these should be in core. I'll explain why for each case.
For page caching, there's one major problem in that when you start
caching the whole page HTML, then the site is no longer dynamically
generated for most cases. There's ways around this, with javascript
and so on, but basically unless you're configured to adapt to it, then
there can be unexpected side effects. Note that there are multiple
possible ways to do whole-page caching, such as the super-cache
approach (save to disk, use .htaccess to serve the pages directly), or
you can use something like Varnish proxying to achieve the same
results.
For object caching, this largely is built into core already, and very
well, just leaving out the "persistent" part. The problem with object
caching is simple: where do you store the objects?
- It makes little to no sense to store objects in the database,
because on the most common cases (shared hosting servers, database
servers shared by multiple people) then the database is already the
major bottleneck that you're trying to use object caching to get away
from. Object caching should *reduce* the number of database calls, it
makes little sense to cache an "object" in the database when the query
to build the object came from the database to begin with. Trust the
mySQL query optimizer, it's smarter than you are.
- Storing objects on disk is generally no good, because disk is
*slow*. Yes, on most systems, filesystem based caching is slow as
heck. Even if you're using uber-duper SSD drives and such, it still
has to sort through the filesystem, and this can be much slower than
communicating even to the DB over the network. DBs, after all, are
designed for fast data storage and retrieval, filesystems.. well, not
so much.
- Using a memory-based cache (xcache, memcached, etc) are perfect.
Persistent (to a point), fast as heck, can handle expiration of data,
wonderful. Also outside the range of like 80% of WP users on cheap or
shared hosting, not supported by like 10% of the rest of the hosts...
it's an uncommon thing. Also, different providers that do provide
these solutions provide different ones. There's dozens of mem-based
cache mechanisms, each of them different. WordPress accommodates these
by providing a very easily pluggable object caching mechanism, and
writing some code to connect the WP Object Cache to any given memory
cache methodology really isn't that tough to do.
Something like Drupal implements caching out of necessity, not choice.
The way Drupal/Joomla/others are architected is very, very different
than WordPress. A default WP site, freshly setup, only maybe does
20-30 queries to build a page. Drupal, last time I tried it, took
80-100. This is because the way those systems work is to store a lot
more of the "functionality" part of the site in the database. When you
can change what fields are available for a post in a UI interface,
then the definitions of the fields and such has to be stored
somewhere, and read to build the site contents. It's a different
approach, and with high amounts of DB access like that, caching
becomes very necessary.
Finally, here's the key point about caching: *most users don't need
it*. If you're a person writing a blog that gets less than 1000 hits a
day, caching ain't going to do much for you. Not really. Sure, your
site might go from 5 seconds down to >1 second load times, but if
you're not getting the traffic anyway, then cache isn't going to make
your traffic increase in any real way. When you start getting some
real traffic, 3000+ hits a day, that's when you need caching. That's
when speed of load starts to really matter. The majority of
WordPress's 70 million+ users aren't getting particularly serious
traffic. Most websites don't, you know.
-Otto
More information about the wp-hackers
mailing list