[wp-hackers] Useful caching

Mark Jaquith mark.wordpress at txfx.net
Mon Sep 25 04:48:43 GMT 2006

On Sep 24, 2006, at 3:19 PM, Matt Mullenweg wrote:

>> 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.)

I've been doing it for a while.  But I'm running additional regex via  
plugins, so what may be a slightly > 1 cost/benefit ratio for me with  
my setup may end up being < 1 for a default WP install.  I was, at  
one point, convinced that this would be of universal benefit, but  
upon more testing, I find that it's only beneficial in certain  
circumstances.  And as the default filters get faster and faster,  
those circumstances are being less and less common.

>> 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).
> 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.

Once people try on WordPress 2.1 with its cachable posts queries  
(DEATH TO $now!), I think they'll be quite pleased with the  
effectiveness of MySQL qcache.  That completely takes care of the  
costly and frequently-accessed front-page queries, reducing them to a  
couple ms.

Mark Jaquith

More information about the wp-hackers mailing list