[wp-hackers] Useful caching

[David Chait]

While that "makes some sense", if it has anything to do with the "built-in 
object cache", it doesn't help the average user -- unless something's 
changed in 2.1. ;)  Last I knew, the object cache was now disabled by 
default, and it actually harms performance in more cases than it helps (in 
some cases, drastically, due to some odd thrash).  Caused/causes a LOT of 
support forum traffic.  And this is especially true on shared servers, and 
cheaper hosting.  I only recommend WP-Cache (or other Staticize derivatives) 
when asked, unless the person is on a dedi box, and knows what they're doing 
(i.e., memcached backend, et al).

That said, always great to do some further caching, if you're really 
targeting the wider audience of folks downloading/using WP.  For all I know, 
the average DL user is no longer the target, and the WPMU-based users are...

One thing I had done (that seemed to make a difference) was to NOT grab * 
from page posts, but only those fields really needed.  ie., if showing only 
excerpts, then grabbing full post content is wasteful, extremely in big-post 
cases.

Frankly, the discussion about caching post-filtered content to the field 
that's sitting in the DB should be re-raised, since that's most of the 
content 'translation' occurring on each pageload, and for large posts that's 
a heavier hit (multiple filters re-processing the body content -- which 
depending on the code can cause PHP to copy the entire block of text over 
and over again...) than the SQL lookup.

At what point do we start discussing rolling WP-Cache/Staticize 
functionality into the core, even if it's just handling certain things (like 
the RSS feeds might be a perfect example)?  Obviously, if you're running any 
random-lookup sidebars, Static-type stuff gets tricky (as it has to be 
wrappered).

Just IMHO. ;)

-d

----- Original Message ----- 
From: "Matt Mullenweg" <m at mullenweg.com>
To: <wp-hackers at lists.automattic.com>
Sent: Sunday, September 24, 2006 7:05 AM
Subject: [wp-hackers] Useful caching


| On most WP blogs I've seen, there are two pages that get far and away
| the most traffic: the front page and the RSS feed. Ofter it's 5-10x the
| amount of traffic of anything else on the site, so it makes sense to
| focus some attention there.
|
| After the built-in object cache has kicked in, there are really only a
| few queries left on the front page, sometimes as few as 5. Here's the
| queries that are left:
|
| 1. Get * wp_posts front page posts.
| 2. Get the categories of those posts.
| 3. Get the postmeta for those posts.
| 4. Get all pages for the menu.
| 5. Get the total number of pubished posts to decide whether to page.
|
| (These combined took 55 milliseconds, 53 of which was 4 and 5.)
|
| Of these, 4 & 5 are discretely cacheable.
|
| 1-3 seems like they could be put into a big $posts object and saved in a
| special case front page cache that's used for the front page and the
| regular RSS feed.
|
| To go a step further, the root RSS feed would be a good candidate for
| wp-cache style output buffer caching, since we don't have to worry about
| things on that page that aren't controled by WP. (And we already send
| the correct caching HTTP headers.)