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