Well maybe, but my experience with using online chats like this is:
- Everyone sits around for several hours babbling, waiting for the other
folks to show up and complaining about the problems they're having logging in.
- By the end, someone has scribbled up a page with a work plan, which
everyone ignores in the future.
- During all this time, they _could_ have been doing something
productive instead...
Depends on the moderator. No moderation=unpredictable, bad moderator=bad result, good moderator=possibly good result. Just like in real life meetings.
Obviously not, since that PHP stuff needs data from the database to work. :)
Duh. But if our database is so slow that it can't even answer simple SELECTs, we can't do anything useful, cache or no cache. And if it isn't, then we should concentrate on the queries which aren't simple. The linkcache might still be one of those bottlenecks (simply because of the sheer number of queries involved), I haven't checked your latest changes to that code.
Our bottleneck is the database server. Fetching stuff from CUR and converting it into HTML is not an issue. 20 pass parser? Add another zero. Until I see evidence that this has any impact on performance, I don't care. Turn off link checking and all pages are rendered lightning fast.
And that would be a pretty piss-poor wiki, wouldn't it? :)
Yes, but this is really one of the more expensive wiki features that also limits all caching options severely. Impossible to work without it, but apparently hard to implement in a scalable fashion.
What would be useful is to maintain a persistent (over several sessions) index of all existing and non existing pages in memory for the link checking. A file on a ramdisk maybe? I think it would be worth giving it a try at least, and not a lot of work.
Sure, it _might_ help. Code it up and see!
I might. I'll have to see if it makes any difference on the relatively small de database which I'm currently using locally. It would have to be optional -- setting up the software is already difficult enough.
Slow saving impacts everyone who tries to edit articles; four edits per minute may be _relatively_ rare compared to page views, but we're still running thousands of edits per day and it's a fundamental part of what a wiki is. It's absolutely vital that editing be both swift and bug-free, and if we can reduce the opportunities for saving to get hung up, so much the better.
Yeah yeah yeah. I still think we should care more about the real showstoppers. But hey, you can always _code it_. (Finally an opportunity to strike back ;-)
If updating these cached pages is so slow and db-intensive that it takes the 'pedia offline for fifteen-twenty minutes (which it does), then nobody's going to want to update the caches (last updated April 9...) and they become outdated and useless.
If this downtime is unacceptable, we might indeed have to think about a query only server with somewhat delayed data availability. This could be a replacement for the sysops, too. Mirroring the Wikipedia database files (raw) should be no issue with a SCSI system, or a low priority copy process.
Watchlists could definitely be improved, haven't seen a good way to do this yet, though. It could be done on page save, but with a much-watched page, this again would add severe drain, with possibly no overall benefit. Improve the SQL and indexes? Maybe, but I'm no SQL guru.
Which Himalayan mountain do we have to climb to find one? :)
Maybe we should stop looking in the Himalayan mountains and start searching the lowlands .. In other words: Don't search those who will do it for society or for the glory. Just hand over the cash and be done with it.
Regards,
Erik