| Addshore added a comment. |
In T184948#4078853, @Multichill wrote:That's what you getting from being a bit more liberal for a long time. Tool rights have to be approved, bot rights have to be approved, all can be revoked when needed. If this really is a problem, take action or clearly identify the problematic tools/bots so admins like me can take action.
In the case of fatemah, the tool isn't a problem really, well, it only allows a user to create a single item with a single request.
In this case it is the users that are calling it too much / too quickly etc.
In T184948#4079845, @Magnus wrote:
Question: WMF knows best when their servers are overloaded. Why not just add a delay for the API response when the servers are under duress? No need for every volunteer to scramble and sink time into altering their tools to preserve the WMF from users trying to get stuff done. I imagine adding something like 0.2 or 0.5 seconds sleep to *every* API edit when under duress might ease the load quickly and quietly. Why make WMFs problem my problem without need?
In T184948#4080624, @Daniel_Mietchen wrote:I like the suggestion of adding a load-dependent server-side delay for API edits.
Eww, that sounds evil. And it would actually result in longer running / more PHP processes on said servers.
In T184948#4089557, @Magnus wrote:So,
- either WMF expose the "overload status" so we can throttle on demand,
- or WMF delay the API response accordingly, so we don't have to do anything,
- or WMF scale to demand :-)
I'm rather pro option 1 here and I believe I have discussed this on another ticket relating to maxlag vs dispatch lag and exposing these in a single API.
For example:
{
"lag": {
"overall" : {
"isLagged" : 1
},
"types": {
"db-replication": {
"raw": 5,
"isLagged": 1
},
"dispatch-clients": {
"raw": 60,
"isLagged": 0
},
"manual": {
"raw": "Large job queue",
"isLagged": 1
}
}
}
}Something like this could also include suggested edit rates for clients / tools to abide by.
The other related ticket I had in mind was T48910
Cc: Edgars2007, Daniel_Mietchen, Pasleim, Magnus, abian, Lucas_Werkmeister_WMDE, ArtixKreiger, Multichill, Mahir256, Framawiki, hoo, Sjoerddebruin, Addshore, Ladsgroup, gerritbot, Aklapper, Lydia_Pintscher, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Lordiis, GoranSMilovanovic, Adik2382, Jayprakash12345, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Zoranzoki21, LawExplorer, Lewizho99, Maathavan, DatGuy, Devwaker, Niklitov, Urbanecm, JEumerus, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, biplabanand, Wikidata-bugs, Snowolf, aude, Dcljr, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
