RecentChanges Performance - Wikitech-l

30 Oct 2002

Hi,

as promised, I have looked a bit into the RC code for the purpose of
possibly implementing a filter. Since Ram-Man seems to be finished with
his script, this is no longer an urgent issue, so we might want to take
a step back and look at the design of SpecialRecentchanges.php etc.
before any further changes.

I have taken the liberty to import the Wikipedia database locally to
find out which operations are fast and which ones are slow even locally.
Long RC queries are quite slow on my machine, in spite of cur_timestamp
being indexed. Even with an index, searching a 350 MB+ table with fairly
random row order may be heavy. (Is there any way to determine if the
index is used, BTW? MySQL has some weird conditions under which it
ignores indexes.) It certainly is slow on my system.

Since this is one of the most commonly accessed functions, we should
really do some performance tuning here, especially as we will sooner or
later have to do stuff like the aforementioned bot-filtering, making
queries even more complex. I noticed that there is already a
recentchanges table that new rows are inserted into upon edits. Is a
move away from SELECTs on the CUR table already in the works? If so,
what is its current status and who's doing it?

Regards,

Erik Moeller
-- 
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de