Last modified: 2011-03-13 18:04:31 UTC
Impliment avglag (average lag), being sum(lag)/count(servers) Although maxlag is useful, its not the most relevant. One server can be having a "bad day", and be really lagged up, but the rest have 0ms of lag. Following maxlag guidelines means that we can't edit as a bot, even though the site may not be under so much stress.. Background: AWB has been (or is still, nearing finishing) reimplemented to use the api for editing. We've decided its wise to follow maxlag, more so for bot editing. So we are using the recommended value of 5ms for bot editing, but this became a pain for users doing semi-automated editing, as they would quite often fall prey to maxlag restrictions preventing editing. We therefore changed this to 20ms for users. Although, this solves some problems for users, it doesn't solve them completely.. And in some cases, editing can be done (and following guidelines) using a multi tabbed browser and some fast clicking.. What is anyone elses opinion on this? I can provide more information if wanted. Thanks!
Created attachment 6554 [details] Attempt at implementing "avglag" Patch attached as per IRC ;)
Created attachment 6555 [details] Improvement on last patch, as per roans comments on irc, and other minor tweaks noticed A side point; i haven't added it to the maintenance patches where maxlag is used.. IMHO it shouldn't be needed there?
+Patch as per Roan being seemingly suprised at it wasn't commited
Committed patch in r58646.
I'm not keen on this. The idea of maxlag is to perform writes as fast as the slowest slave will allow. If you keep doing writes until half the slaves are overloaded, the slowest slaves will be past 30s lag and completely depooled. That doesn't seem like an appropriate place to stop writing.
(In reply to comment #0) > Background: > AWB has been (or is still, nearing finishing) reimplemented to use the api for > editing. We've decided its wise to follow maxlag, more so for bot editing. > > So we are using the recommended value of 5ms for bot editing, but this became a > pain for users doing semi-automated editing, as they would quite often fall > prey to maxlag restrictions preventing editing. We therefore changed this to > 20ms for users. Although, this solves some problems for users, it doesn't solve > them completely.. And in some cases, editing can be done (and following > guidelines) using a multi tabbed browser and some fast clicking.. Do you mean 5 s? 5 ms is probably more than the latency between the master and some slaves on a bad day.
Yeah, i do. 5ms wouldn't be worth bothering about ;)
I guess it kinda depends on how this is used, and the nature of the client. Bots performing maintenance tasks can afford to wait for maxlag to drop, but tools like AWB that aim to provide relatively fast user interaction don't want to wait all day. In a scenario where one slave is badly lagged but the rest is not, avglag could help for these slightly higher priority edits. Of course it would need to be set to a low value like 2.
(In reply to comment #8) > I guess it kinda depends on how this is used, and the nature of the client. > Bots performing maintenance tasks can afford to wait for maxlag to drop, but > tools like AWB that aim to provide relatively fast user interaction don't want > to wait all day. In a scenario where one slave is badly lagged but the rest is > not, avglag could help for these slightly higher priority edits. Of course it > would need to be set to a low value like 2. Well, if your approach is "keep writing regardless of whether you lag a slave out until it's depooled", then you might as well not bother checking for slave lag at all.
(In reply to comment #8) > I guess it kinda depends on how this is used, and the nature of the client. > Bots performing maintenance tasks can afford to wait for maxlag to drop, but > tools like AWB that aim to provide relatively fast user interaction don't want > to wait all day. In a scenario where one slave is badly lagged but the rest is > not, avglag could help for these slightly higher priority edits. Of course it > would need to be set to a low value like 2. If they can't afford to wait, they should not specify a maxlag value. Then they'll get the same lag policy as ordinary editors.
Reverted.
