[wp-hackers] 2.next - faster

[David Chait]

Have you tried WP-Cache on your system?  Most of what you discuss would be 
solved with WP-Cache built-in to WP in the future (on an option, of course).

I believe that caching should occur at the page/request level whenever 
possible -- even though my own site right now won't work well, as I have 
truly dynamic content (ads, etc.) that are invoked directly in the php 
rather than via secondary content loading (img tag, javascript, etc.).  With 
page caching in place, very little else needs be optimized/cached.

Now, given that, some of the things you've pointed out are useful bits. 
Even with page caching, things that invalidate the cache frequently enough 
(i.e., new comments) could still be an impact on large/heavy sites unless 
there is other performance enhancements.

-d

----- Original Message ----- 
From: "Sebastian Herp" <newsletter at scytheman.net>
To: <wp-hackers at lists.automattic.com>
Sent: Tuesday, February 07, 2006 11:57 AM
Subject: Re: [wp-hackers] 2.next - faster


| Speeding things up in 2.next would be nice. Making the function
| "current_time()" pluggable (overwriting it with something using the
| value from the following plugin), together with a plugin like the one
| found here (http://txfx.net/files/wordpress/post-query-accelerator.phps)
| would greatly improve the chance that a query can be cached by mysql
| itself. I did this on a blog and the overall time needed for queries is
| now 30ms if they are all in the mysql cache which is the case most of
| the time!!!
|
| However, this is not the main time eater on my setup. It's mainly the
| php code execution. Wordpress (always on my server and speaking of the
| frontpage) takes 150 to 200 ms to get to the point where it actually
| outputs html. The other big thing is the content loop. Formatting every
| posting each time takes a while. Getting categories and other
| information also eats some milliseconds. Summed up the content display
| stuff takes around 300 ms to execute.
|