On lun, 2002-05-13 at 00:36, Lars Aronsson wrote:
20020511 Sat 13:20:00 769.98 200 http://www.wikipedia.com/wiki/Sweden 13360 20020511 Sat 13:30:00 2549.62 http://www.wikipedia.com/wiki/Sweden 0 20020511 Sat 13:40:00 2288.51 200 http://www.wikipedia.com/wiki/Sweden 4577
[...]
20020512 Sun 11:00:00 327.15 200 http://www.wikipedia.com/wiki/Sweden 12807 20020512 Sun 11:10:00 2549.62 http://www.wikipedia.com/wiki/Sweden 0 20020512 Sun 11:20:00 2549.71 http://www.wikipedia.com/wiki/Sweden 0 20020512 Sun 11:30:00 2549.82 http://www.wikipedia.com/wiki/Sweden 0 20020512 Sun 12:10:00 481.58 200 http://www.wikipedia.com/wiki/Sweden 4576
Woo-hoo! Thanks for the detailed stats, I think I've got it figured out now. The timeouts just before the blanking look VERY suspicious...
Here's what I think is going on:
* The main database query times out on a page load.
* wikiPage::load() doesn't check the return code from mysql_query() (oops!) and ends up with nothing for, among other things, $this->cache and $this->text.
* Since the cache is empty (not != ""), the text is re-rendered. Blank text actually ends up rendering to "<p><p>\n<p>\n". (Is that what you see if you check the HTML code of the blank pages?)
* The new rendered blankness gets saved in the cache. (For some reason, the PHP process for the page hasn't been killed for being around too long by this point.)
* Subsequent page views get shown with the pseudo-blank cache, since it's not actually a null string (hence, != "")
So, it's not THE caching bug, but it's A caching bug.
Fix: always check return codes! I've added a quick check to wikiPage::load() for the main query, so if it can't execute the query it should spit out an error message and _not_ cache the result. All the other queries really should be checked too, though.
-- brion vibber (brion @ pobox.com)