[wp-hackers] 2.next - faster
newsletter at scytheman.net
Tue Feb 7 16:57:07 GMT 2006
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
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.
So it's nearly 500 ms for code execution version 30 ms for mysql queries
... fix the code I say :-) We can savely assume that hosters use
powerful hardware with caches everywhere. They would be stupid not to ...
What needs to be done to improve Wordpress' performance (in my opinion)?
1. don't use now() or aquivalents in any query! That one should be core
and not solved with a plugin!
2. find out what takes so long before content is displayed (it's not a
3. don't filter the content of posts/comments each time they are
displayed, instead do it on updates of the content only (the columns for
that exist in the database) This should also be core and not solved with
4. fix the content loop! The posts array should include all necessary
information (kategories with names, comment cound, etc) without the need
for seperate queries or whatever happens in those getter-functions that
lets them eat away so many precious milliseconds.
5. encourage plugin authors of popular plugins to do some performance
tuning, too ;-)
Scott johnson wrote:
> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL". For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.
> Faster in what environment??? I'm happy to contribute ideas but given the
> spectrum of sites WP runs on this question has major ramifications
More information about the wp-hackers