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