Mailing List Archive: Speedup

I finished working on the speedup for now. Some of my test data (Athlon
1800):

ab -n100 -c8 (for the Biology article):
* uncached: ca. 11 requests/sec.
* cached: ca. 20 requests/sec.

This is about 20% faster compared to what I started with this morning.

The real time killer is the {{NUMBEROFARTICLES}} variable on the main page.
Its use increases the time per page by a factor of about 10! Only a change
of the database can help here.

Another thing that takes a lot of time is the headed or the Recent Changes
page. I guess since all the links there have to be checked every time the
page is displayed, it increases the load on the database quite a bit. On my
(short) local Recent Changes page, the header text alone is responsible for
about 20% of the total rendering time. We should probably force the Recent
Changes page *not* to look for existing articles in the header text.

Everyone, please test the changes I made (especially the login procedure)
for bugy, so Jimbo can use the current version ASAP.

Magnus

Magnus Manske wrote:
> The real time killer is the {{NUMBEROFARTICLES}} variable on the main page.
> Its use increases the time per page by a factor of about 10! Only a change
> of the database can help here.

Of course, this is a fairly useless feature anyway. I think it should
be removed! Speed is far more important than cute features. We could
have a cron job calculate the number of articles every night, or every
week, and post it on a plain old text file publicly accessible, and
people who want to do it could go there to look up the latest number
and update the homepage from time to time.

> Another thing that takes a lot of time is the headed or the Recent Changes
> page. I guess since all the links there have to be checked every time the
> page is displayed, it increases the load on the database quite a bit. On my
> (short) local Recent Changes page, the header text alone is responsible for
> about 20% of the total rendering time. We should probably force the Recent
> Changes page *not* to look for existing articles in the header text.

If a page appears on RecentChanges, doesn't that automatically imply
that the page exists? So why do we need to check all the links there?
If we in some rare cases show a page there as if it exists, when it
does not, what's the harm?

If I don't hear about any showstoppers from the other developers, I'll upgrade
to this version later tonight or tomorrow morning.

--Jimbo