Topic on User talk:MisterSynergy

Jump to navigation Jump to search
Sjoerddebruin (talkcontribs)
MisterSynergy (talkcontribs)

I do so, max lag is fine all the day. My bot uses pywikibot with standard config (maxlag=5), thus it slows down automatically as soon as there is a problem with lag. I have experienced that several times in the past, but this night everything went smoothly.

Sjoerddebruin (talkcontribs)

I thought max lag also influenced the edit rate, but good to know. Guess this task needs some higher priority then.

MisterSynergy (talkcontribs)

I found this graph re WDQS lag in the phab, and now I see the problem. As the phab states, WDQS lag is apparently not factored in into the lag parameter, thus my bot cannot see this problem, and consequently it cannot slow down as well.

Last November I asked for current rate limits at Wikidata:Contact the development team/Archive/2018/11#Current rate limits, and the answer basically was "just respect maxlag parameter and you are fine". This is what I do. I cannot monitor the WDQS lag graph manually all the time, as that bot batch lasts many days and potentially weeks even at something like 117 edits per minute.

In order to recude the load, I slowed down to 60/min. I don't want to cease bot activity completely, or wait for the rare and small time windows where WDQS lag is fine to start for short sprints. This is apparently another bottleneck which needs to be fixed quickly, either by integrating the problem into the lag parameter so that bots slow down automatically, or by making the infrastructure stronger so that this does not happen again. The WDQS graph suggests that WDQS lag is rather the rule than the exception these days.