Change Details

We've repeatedly had issues because too many pages were being created in a short time. We should limit this to keep the infrastructure sane. Suggested config edit by Daniel with modification by Lydia: '+wikidatawiki' => [ 'edit' => [ // 8 ed./min per each non-autoconfirmed, or group thereof from same IP 'ip' => [ 8, 60 ], 'newbie' => [ 8, 60 ], // 100 ed./min for regular users (including bots and sysops) 'user' => [ 100, 60 ], ], 'create' => [ // 4 creations/min per each non-autoconfirmed, or group thereof from same IP 'ip' => [ 4, 60 ], 'newbie' => [ 4, 60 ], // 20 creations/min for regular users (including bots and sysops) 'user' => [ 20, 60 ], ], ],

We've repeatedly had issues because too many pages were being created and/or edited in a short time. We need to limit this to keep the infrastructure sane. =Why is this a problem?= When people create or edit items too fast on Wikidata it causes problems in various parts of the infrastructure: * dispatching changes to the clients (Wikipedias etc) so they show up there in recent changes and watchlist is delayed * job queue on the clients gets overloaded due to page purges and reparsings * the recent changes table on the clients grows too big * the replication lag between the database servers grows to unacceptable sizes * the query service misses updates * assignment of new entity IDs gets locked * ORES scoring can't keep up =Current monitoring= * replication lag (already taken into account by a lot of tools/bots) * dispatch lag (often not taken into account yet) =Next steps= * limit max page creation rate to 40/min per account * limit max edit rate to 80/min per account * Add an API parameter analogue to "maxLag" for dispatch lag: T192026

We've repeatedly had issues because too many pages were being created and/or edited in a short time. We shouldWe need to limit this to keep the infrastructure sane. Suggested config edit by Daniel with modification by Lydia: '+wikidatawiki' => [=Why is this a problem?= 'edit' => [When people create or edit items too fast on Wikidata it causes problems in various parts of the infrastructure: // 8 ed./min per each non-autoconfirmed, or gro* dispatching changes to the clients (Wikipedias etc) so they show up thereof from same IP in recent changes and watchlist is delayed 'ip' => [ 8, 60 ],* job queue on the clients gets overloaded due to page purges and reparsings 'newbie' => [ 8, 60 ],* the recent changes table on the clients grows too big // 100 ed./min for regular users (including bots and sysops)* the replication lag between the database servers grows to unacceptable sizes 'user' => [ 100, 60 ],* the query service misses updates ], 'create' => [ // 4 creations/min per each non-autoconfirmed, or group thereof from same IP* assignment of new entity IDs gets locked 'ip' => [ 4, 60 ],* ORES scoring can't keep up =Current monitoring= 'newbie' => [ 4, 60 ],* replication lag (already taken into account by a lot of tools/bots) // 20 creations/min for regular users (including bots and sysops)* dispatch lag (often not taken into account yet) =Next steps= 'user' => [ 20, 60 ],* limit max page creation rate to 40/min per account ],* limit max edit rate to 80/min per account ],* Add an API parameter analogue to "maxLag" for dispatch lag: T192026