I suggest to add two new fields to the database (cur table)
* cur_namespace (varchar) so articles can be distinguished by namespace
without using the "LIKE" MySQL query (this was mentioned before)
* cur_is_redirect (boolean) so #REDIRECT pages can be excluded likewise
As you can see, I now try to discuss things instead of just doing them ;)
Why is the Main Page sometimes blank?
This has been the case on Friday 5:00 am - 6:50 am PDT
and on Saturday 6:20 am - 8:30 am PDT.
Then at 8:36 am PDT it is back in full!
(But right now the Sweden page is blank instead!)
The server has also been unavailable for some periods. Is there a
natural explanation to this, or does it need to be investigated?
wojtek pobratyn wrote (on wikipedia-l):
> same here, the 'pedia is dead. Funnily enough when I try to ping the
> server I get an 80% packet loss.
The technical discussion is taking place on wikitech-l(a)nupedia.com.
This is a short summary and unofficial status report.
In the last few weeks, the Wikipedia webserver has been very slow,
depending on new functions being added without enough concern about
their performance under high load.
At 5 pm on Thursday May 9, Jimmy disabled some of the functions that
consumed too much time, and there was an instant improvement in
response time. The removed functionality include the "talk" links.
The implementation is studied right now, and an improved version will
probably be installed in the next few days. At this point, I don't
think more programmers are needed, but if you want to stay informed,
you can join the wikitech-l to follow the reports and discussions.
It is good to see that so many are concerned to have Wikipedia back in
full operation, with all the necessary functionality. However, it
does surprise me that so few were complaining about the absurdly slow
response times in the week before.
There are still periods when the server seems totally unavailable, and
the last hour seems to be one such case. In the preceeding 24 hours,
the response time for the front page ranged from 0.95 to 12.31 seconds,
with an average of 2.18 seconds. This could still be improved, but it
is actually very fast for Wikipedia.
The problems are with the English Wikipedia, which receives most
of the traffic. The international versions run on the same server,
and are slowed down by the poor overall performance of the system.
Lars Aronsson (lars(a)aronsson.se)
Teknikringen 1e, SE-583 30 Linuxköping, Sweden
As promised, I took some time today to engage in bugfixing.
* Talk page links are back, and fast
* The auto-wikification button is now a user option, turned off by default
I also went through the code, looking for SQL queries containing "LIKE", and
deactivated one more. On my local machine, response times are now less than
half of what they were on Thursday morning, before the "Need for Speed";)
The only working queries containing "LIKE" are now in the statistics page,
the orphans page, the main page (through the variable that counts the
articles), and the search page (though I don't remember if these queries are
deactivated; I think so).
Jimbo, please install the current version to get the 'pedia back to full
power. And you others, don't get a speeding ticket when browsing this
>I suspect the problem may be this query:
> SELECT cur_title FROM cur WHERE cur_title LIKE "%:$n"
Wow! This is a pig. Linear search (with regular expression) through the
whole database for every single page served :-)
There should not be any LIKE operators in the code whatsoever, since
they cannot use the index. The quick and dirty fix would be to
explicitly search for the page in other namespaces, like:
SELECT cur_title FROM cur
WHERE cur_title = "wikipedia:$n" OR
this uses the index on cur_title and is quick. A much
cleaner solution would be to have an additional field "namespace" in
the database. Encoding namespaces in the article title is a
I assume this is because I'm returning an empty array from the getOtherNamespaces
----- Forwarded message from tshell(a)bomis.com -----
Date: Thu, 9 May 2002 18:33:04 -0700 (PDT)
To: jwales <jwales(a)bomis.com>
Subject: Wikipedia talk link
Do you know what happened to the Talk link on Wikipedia article pages?
Now there is a link to today's date, instead of a link to the Talk page.
----- End forwarded message -----
> I'm suggesting ways to find such numbers, but I don't
> have access to update the source code.
I agree that it would be useful to get numbers. Why don't you prepare
and test your patch and post it here (or get commit access from
I think it would be best to simply report the times in an HTML comment
attached to every served file, as you suggested earlier. This way we
can all perform our own tests from home and no artificial bottleneck
slowdowns are introduced (which could occur if the time data were logged in
a central file).
I took LDC's advice and did most of the copy-and-past work for the PHP skin
classes (as I was the one responsible for the mess in the first place;) and
added the following files to the CVS:
* wikiSkins.php (has a dummy class and includes all other skins)
* wikiSkinStandard (the good ol' boring one)
* wikiSkinNostalgy (for those Perl fans)
* wikiSkinStarTrek (not really working right now!)
For Standard and CologneBlue, there are stylesheet functions in place. The
stylesheet function in wikiUser.php is hereby obsolete (I didn't remove it
Otherwise, the classes contain functions for header, footer, middle and
I noticed that the namespace backgrounds are not working anymore after the
change. I couldn't figure out why. Someone please have a look. And if you're
at it, try to fix the Star Trek skin as well ;)
In time, I'll get the script just big enough to halt the server
I identified the "getOtherNamespaces" function in wikiPage.php as a major bad
guy. It is used to link to the appropriate Talk namespace in the sidebar and
the footer. On my test installation, returning no other namespaces (an empty
array) cuts the time to generate a page in half! (Tested with the "Biology"
article using ab -n 20 -c 4)
I don't have time right now to fix this, someone please!!!!!!! help :)