--- Delirium <delirium(a)hackish.org> wrote:
> I've talked to a few other people who feel similarly, though I
> don't know what the most common preference would be. If there's
> queueing, at least you know your request will get served
> eventually, even if you have to go get a cup of coffee first; with
> the error-message responses, you just have to keep hitting reload,
> which is more irritating.
When demand outstrips supply, it's pretty arbitrary how long you wait
before you serve the error message, it's going to happen eventually. In
such a situation, the idea of serving error messages is to discourage
further traffic. I know it's irritating, but there comes a point where
the only option is to deny service and hope people find some other way
to get the information they want. Using a mirror is the obvious option.
The situation is different with writes, in that it's better if we let
the user know that there is a problem before they go to the trouble of
making the edit. If we have to reduce write load, the best way to do it
is with read-only mode. That way we don't end up with hundreds of edits
queued up in the master database, with no-one able to retrieve diffs for
them or review them in any way. That, remember, was Presroi's original
complaint.
Queueing reads for 10 minutes before serving an error message does
no-one any good.
Daniel Mayer wrote:
Also irritating is the fact that nobody seems to care
about locking
the database from edits when things slow down like this. So those who
are are on RC patrol have the choice of letting vandalism through,
or sitting there frustrated seeing all their rollbacks fail 3 or 4
times before sticking. Everybody else gets frustrated as well ;
seeing their edits fail.
When service gets this bad PLEASE lock the database from edits until
service improves.
Maybe you didn't notice, part of my proposal was to do that automatically.
Timwi wrote:
With several thousands requests per second, how is any
server ever
going to "catch up" completely? The way I understand replication,
the servers are always out of date at least by the time it takes for
the master to send an update to all the slaves?
1500 requests per second at the squid, but only 50 updates per second
and 6 inserts per second (as I type this post). The slaves spend a
significant proportion of their time with their replication thread in
"waiting for master" mode. And we can always add a grace period of a few
hundred milliseconds, if necessary.
Timwi also wrote:
Personally, I would think that serving an error
message only becomes
appropriate when there is an error. Extreme slowness is not an
error. I would prefer for a request to take half an hour to complete
than to have to reload every five minutes for half an hour, and the
request still hasn't completed because it keeps timing out.
Sorry, we can't queue read requests forever due to the apache connection
limit problem I described in the previous post.
-- Tim Starling