Ladsgroup added a comment.
In T252091#6134865 <https://phabricator.wikimedia.org/T252091#6134865>, @Krinkle wrote: > @Ladsgroup wrote: > >> […] The edit rate on this wiki has been going up to 1,000 edits per minute and has been testing our infrastructure scalability […] The edits have been mostly done by bots […] and bot operators want to edit in full speed when the infrastructure is quiet and forcing an arbitrary number […] limits bots in times that **the infrastructure can actually take more**. > > (Emphasis mine). > > @Ladsgroup wrote: > >> WDQS updater can't keep up and […] we need to keep in mind that there always will be a bottleneck. > > It sounds like there are no times where the infrastructure can just handle it all at the current rate. The above suggests that the current rate limit is too high, because we can't keep up with that rate even at normal/quiet times. Right? No. Let me clarify: - By "the infrastructure can actually take more" I mean the times that there are less edits happening for example midnight when human edits are low. or days that a bot is broken/has nothing to do and other bots can go faster - "The above suggests that the current rate limit is too high," this is not correct, the problem is that there is no rate limit for bots at all. The group explicitly doesn't have a rate limit. Adding such ratelimit was tried and caused lots of issues (even with a pretty high number). In other words, inside the mediawiki, for bots, we are at mercy of them and based on contracts and API etiquettes, we tell them the pressure on the server and they adjust their speed based on that and maxlag is a proxy of a metric on the pressure of the server. If any bot doesn't respect maxlag, they'll be blocked. but the problem is that maxlag is not a good enough metrics to bots. > If we lower the rate limit, would this pattern not go away? As I said before, there's no ratelimit for bots. > I suppose it could come back if bots use their burst capacity within a single minute, or when there are many different/new bots starting to do the same thing. Bursts of a lots of activity are fine, it makes all bots stop for system to recover, the problem right now is that the edits are too high virtually all the time. > In that case, the global protections of `maxlag` and kick in automatically to restore us. Is that not good enough? Would the global rate limit behave differently in practice? Yes it would be different, it would keep the flow under control all the time instead of the oscillation. > @Ladsgroup wrote: > >> […] This has been oscillating like this for months: >> F31805674: image.png <https://phabricator.wikimedia.org/F31805674> > > It isn't said explicitly, but it sounds the oscillating pattern is considered a problem. Is that right? What kinds of problems is it causing, and for whom/what? I can understand that regularly reaching a lag of 5s is not great, but it seems like an expected outcome if we set the bot maxlag to 5s. If we want the "situation normal" lag peaks to be lower, then we should set that maxlag parameter lower. Well, it is a big problem. Please read T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service) <https://phabricator.wikimedia.org/T243701> and I mentioned that this pattern even broke CI (travis) of pywikibot. TASK DETAIL https://phabricator.wikimedia.org/T252091 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup Cc: daniel, Krinkle, Aklapper, Jakob_WMDE, Lydia_Pintscher, WMDE-leszek, darthmon_wmde, Addshore, Ladsgroup, DannyS712, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, RazeSoldier, QZanden, LawExplorer, elukey, _jensen, rosalieper, D3r1ck01, Scott_WUaS, Jonas, Izno, SBisson, Perhelion, Wikidata-bugs, Base, aude, GWicke, Bawolff, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
