[wp-hackers] wordpress optimizations

denis at semiologic.com denis at semiologic.com
Sun Apr 17 12:52:19 GMT 2005

Quoting Podz <podz at tamba2.org.uk>:

> Okay so that comes down to how exactly a user implements the actual plugins
but from that list some basics must surely be able to be distilled and written
up ?

When I started this discussion, I had no other idea in mind than working towards
coming up with said list. I feel this is a part of WordPress that will greatly
benefit from teamwork.

> The query counter - is that a measure ? Is less better or can the count be
higher but more efficient ?

The query counter is a highly significant measure, since it measures the number
of return trips to your sql server. The three chief resource hoggers in
softwares are the use of complex algorithms, exploring huge chunks of decision
trees that you could have avoided with a simple test before hand, and the use
of resources located elsewhere.

It is thus in your interest to minimize the number of accesses to your database.
But it is not in your interest to select * from DB either, since you'll end up
manipulating hordes of arrays and objects, and thus using complex algorithms
that are likely to underperform accessing the DB multiple times.

With a real SQL language, you would call a stored procedure that would return a
batch of relevant data sets in a mere one trip to your SQL server per page.
With MySQL, a few of the optimizations that would be in the stored procedure
end up in the php. These include:

- Caching options, categories, and the like, since they are used often
- Triggering the latter to be cached only on first request
- including that little extra something in a query that makes 80% other calls to
another query irrelevant. For instance:

  *, meta_value as page_template
  postmeta ON posts.ID = postmeta.post_id
  posts.post_status = 'static'
  AND meta_key = '_wp_page_template'
  AND ...

- changing the tables to reflect that 80% of calls to a second query are cruft
(e.g. _wp_page_template could also be used for posts)
- storing aggregate results to avoid queries altogether (e.g. storing the number
of posts in a cat, the number of comments in a post, etc.), but i'd recommend
against this for wp as doing so without a proper SQL language (data integrity,
triggers, functions and stored procedures) is a recipe for disasters

> What this actually comes down to though is how many people it affects
> and how many it could affect. If the second number could get large then
> maybe something needs addressing now ?

I trust it affects everyone, and that it is low priority for most people.


This message was sent using IMP, the Internet Messaging Program.

More information about the wp-hackers mailing list