[wp-hackers] Freezing $now to increase query cache benefit

[David Chait]

<offtopic>
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.
</offtopic>

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?

-d

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