[wp-hackers] Freezing $now to increase query cache benefit
davebytes at comcast.net
Fri Jan 6 03:50:45 GMT 2006
I'd be interested to hear (offline) your success on tuning a 256MB VPS...
I've avoided moving to a VPS as 512MB seems needed if you get cpanel/plesk
(for those of us somewhat-linux-impaired folks!), and those are expensive
plans -- comparable at times to a low-end dedi.
That's a really great solution you came up with, and fits nicely with other
internal caching approaches. If 2.0 hasn't done something similar, might be
worth considering... BUT...
There's a strong alternative: don't filter based on post date at all, and
move future-posts out of the 'normal flow'. Future posts already want to
ping when they 'arrive', so the same cron/timing facility could actually
change a post state from, say, 'future' to 'publish' when the post time
passes. That'd eliminate the extra query param entirely from the 'average'
query (I could see wanting to filter by date for other reasons... but I
think this'd all work nicely). Thoughts?
----- Original Message -----
From: "Mark Jaquith" <mark.wordpress at txfx.net>
Sent: Thursday, January 05, 2006 8:22 PM
|The next solution I looked at was MySQL's qcache, which caches
| queries. The problem here is that the main post query uses " AND
| post_date_gmt <= '$now' " ... and $now changes on each load. qcache
| requires the query to be identical for it to be served from the query
| cache. And then I though... WHY does $now need to reflect the
| current time? The reason that $now is there is to prevent future
| posts from appearing, so why not just make that date reflect the date/
| time of the most recently published post?
| So, I wrote a plugin to do just that. It updates an option with the
| date/time of the most recent published post (updated on edit, save,
| It made a HELL of a difference. The main post query, when grabbed
| from the query cache, now takes less than 1/100 of a second, as
| compared to 3-15 seconds before.
More information about the wp-hackers