[wp-hackers] Useful caching
m at mullenweg.com
Sun Sep 24 19:19:01 GMT 2006
David Chait wrote:
> 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).
I'm not suggesting we change the current default behaviour, just to plug
in our current cache infrastructure (which is on by default) to look at
these high-use situations.
> 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
That's a good idea, I don't even think we need excerpts.
> 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.
You're welcome to try it, just write a loop to dump the output of
the_content into that DB field, and then modify the_content on your site
to use that field instead of running filters. It's been a while since I
ran that test, but I couldn't measure a significant difference. (And
that was when our filters and regex were less efficient.)
> 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
I think wp-cache is at the opposite end of the spectrum from where WP is
today, and that's good. However I think we could move a little more
toward the middle without creating any additional complexity for the user.
This might be moot, since after some tweaking and testing I found that
the built-in MySQL query cache brought the total query time down to 2
milliseconds. The remaining 298 in the page execution time was PHP.
http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
More information about the wp-hackers