Hi!

With all the talk going on, I wanted to give you my little thoughts. I am more on the wiki user side, so keep that in mind (I do know php, so I am not a complete dork)

1) how about a query cache (for edits and searches). http://www.vbulletin.com/ (not OpenSource), does something like that for search queries: http://forum.doom9.org/search.php Basically you instantly see a html page, which tells you that the search is in progress. This looks good for the user. The page reload can probably be configured in intervals. That way the best server load (e.g: 4 searches / second) can be obtained and it will never be used more that what you specify I think http://www.phpbb.com/downloads.php (GPL'ed) can do the same, but I am not sure. The thing is, when users see, that the server is doing something, they will not try to hit refresh every few seconds, because they think it helps (which it doesn't). User feedback is and always should be top priority.

2) What is really slowing down wikipedia As I see it, not everyone agrees on that. I am also guessing it's the db, and not the php-code that does the rendering. Maybe someone can somehow put this together, like searches (7/second avg. - serverload: 30%), edit(1/second: - serverload: 5%), recentchanges ( 5/second, 25% load), etc. maybe some real numbers will help focus on the problem. So If I am guessing right, and the sql-query for the searches takes the most time, building up a queue for searches like above might satisfy users (at least they know know something is happening) and it will reduce serverload.

I hope this helps the discussion somewhat.

Cheers Leo