Jim accidentally sent this just to me, I'm sending it back to the list:
On mer, 2002-04-10 at 18:27, Jimmy Wales wrote:
Brion L. VIBBER wrote:
My best
guess is that the parsing and lookups on regular pages are
currently the main load, not editing or exotic database queries -- is
this right?
Not a clue. Initially, the database certainly was the main load, but I
haven't heard any newer figures. Jimbo?
I'll reset the slow-query log and make a new version available after a few
hours of data collection.
We used to cache rendered articles, but Jimbo
disabled this feature some
time ago, claiming he was unable to find a performance advantage. (See
mailing list archives circa February 13.)
But, I'm willing to try it again.
Personally, I've always find that idea
suspicious; caching is definitely
faster on my test machine, and is going to be a particularly big help
with, say, long pages full of HTML tables! But then, my test machine has
a much much lower load to deal with than the real Wikipedia. :)
Nonetheless, if cacheing really isn't helping, that's because it's not
doing something right. It should be found, fixed, and reenabled.
I would say that I agree with that.
Here's a question for everyone.
Let's say we have some portion of the page pre-calculated and cached.
Is it faster to keep that cached text *in the database*, or *on the
hard drive*?
I'm very strongly biased towards thinking that keeping it on the hard
drive is faster, and by a significant margin, but only because I've
never tested it and because I know (from long experience at Bomis) that
opening up a text file on disk and spitting it out can be *really* fast,
if the machine has enough ram such that the filesystem can cache lots of
popular files in memory.
But, everything I read about MySQL talks about how screamingly fast it
allegedly is, so...
--Jimbo