Topic on User talk:Magnus Manske

I have just seen that QuickStatements did not only slow down on FactGrid (from 92 edits per minute to one edit every 6 seconds) but also on Wikidata - was there a connection? https://database.factgrid.de/quickstatements/# cheers --~~~~~

replication lag flag issues, should be solved now...

Unfortunately QS has gone on being desperately slow -- see Wikidata:Project_chat#QuickStatements_is_very_slow_today

Logged in as JhealdBatch (talk • contribs • logs), running from a browser window, on Friday it was crawling along at 6 edits/minute. Today (Sunday afternoon) it's even slower, at only two edits a minute.

It looks as if a total quota of about 60 or 80 edits/minute is being shared out amongst everybody running it under their own user ID, rather than user ID getting an individual rate quota of about that.

I have deactivated all the breaks for browser mode now. However, these edits still depend on a module that has to respect replication lag errors from Wikidata. If Wikidata says "wait 5 seconds", it will. Otherwise, QuickStatements might get blocked. If it's a larger batch, just run it in the background...

Looking at edit-groups , that seems to have done the trick. Thanks!! People are once again getting approaching 60 edits a minute.

But running things in the background is generally not an option for larger jobs, if all the background jobs are having to share a combined quota of 60 edits a minute. If someone's trying to add a statement to 30,000 items, plus a qualifier, plus a reference, that is simply not feasible at 2 edits a minute. It would take a month, even running 24/7. That kind of job needs to be possible in no more than a day.

The limits are not made by me, but by the Wikidata server. I expect a "your tool is editing too fast" message from Higher any minute. I try to keep things running, between a rock and a hard place. If you just start dozens of tabs editing away, you'll end up not editing at all.

For the record, I never have QS active in more than a single tab; and I very very seldom run background batches, because of the slowness noted above.

I'm sorry if I made you feel 'got at', Magnus. That wasn't my intention. I know these limits aren't you fault, and we owe you constant and immense thanks that we have these tools to work with at all.

But as I wrote at project chat, this is core infrastructure that people building the database rely on, and I do sometimes think the management team need to have a more lively awareness of that, rather more at the front of their minds.