[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Ladsgroup added a comment. In T243701#6152282 , @Gehel wrote: > I'm wondering if exposing both MySQL lag and WDQS lag as a single value is wise. Those 2 lags represent different things and clients should be free to behave differently de

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Gehel added a comment. In T243701#5985617 , @Ladsgroup wrote: > I think this would be a decision by @Lydia_Pintscher plus we need more info from Search platform to know if the issue of WDQS is going to get fixed soon or not (or any ETA)

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Dvorapa added a comment. Is this some random spike? :D F31763816: obrazek.png TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Dvorapa Cc: Masti,

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Dvorapa added a comment. Is there any short-term temporary solution until RFC gets done? Perhaps hardcode maxlag=4? Or temporarily revert WDQS inclusion into maxlag? TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/e

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Ladsgroup added a comment. In T243701#5973374 , @Dvorapa wrote: > Any news? From possible solutions like T238751 , T240442 , T245144

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Vojtech.dostal added a comment. This is also extremely important for OpenRefine users. We cannot push our reconciliations into Wikidata if the lag > maxlag. TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailprefe

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Bugreporter added a comment. By default pywikibot will do one edit every 10 seconds (or longer if you use parallel processes). This may be overrided by setting -pt:1 (or 0) and some bots runs under it. This task will unconditionally throttle it when lag is high (but they can still edit in a

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Strainu added a comment. In T243701#5884801 , @Ladsgroup wrote: > I have been thinking about this and I think I have a suggestion. bots and tools, should respect maxlag **before** it reaches the threshold. We need to return the value of

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Bugreporter added a comment. Currently Widar use a policy of sleeping 3x+1 second if the lag (x second) is higher than one second. PetScan run batches five in parallel, so for a lag of 10 seconds PetScan make 5 edits every 31 second. TASK DETAIL https://phabricator.wikimedia.org/T243701 E

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Ladsgroup added a comment. In T243701#5880988 , @Bugreporter wrote: > The only way to resolve the issue is increase the rate of edit Query Updater can handle, or reduce the number of triple changes each edit. Yes and no. Yes, WDQS u

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Bugreporter added a comment. The only way to resolve the issue is increase the rate of edit Query Updater can handle. TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bugreporter Cc: Bugreporte

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lea_Lacroix_WMDE added a comment. Thanks all for your feedback. Since the change we perform didn't have the expected results, we're going to revert it today, and keep looking for sustainable solutions. TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabr

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

ArthurPSmith added a comment. @Bugreporter > I think increase the factor will not make thing better, it only increase the oscillating period Yes that does seem to have happened - instead of a roughly 20 minute cycle, we now have about a 1-hour cycle. TASK DETAIL https://phabricat

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Bugreporter added a comment. If the rate of edit Query Updater can handle is a constant, changing the factor will not affect the average edit rate, nor the proportion of time the lag under a specific maxlag (assuming the rate of edit over maxlag and under maxlag are constants independent of

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Bugreporter added a comment. I think increase the factor will not make thing better, it only increase the oscillating period. It even make query service worse (more lagged). See https://grafana.wikimedia.org/d/00170/wikidata-edits?orgId=1&from=1581429584959&to=1581542357438 TASK DET

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lea_Lacroix_WMDE added a comment. We just increased the factor to 180 . If you are running a bot and still encountering issues frequently, please let us know. TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabr

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lea_Lacroix_WMDE added a comment. Hello all, Here are some news: we are going to try and increase the maxlag connected to the WDQS to **15min **, to see how it goes and if most of the problems you encounter still occurs. This change should be appl

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Ladsgroup added a comment. Yes, I think `wgWikidataOrgQueryServiceMaxLagFactor` should be way higher. Something like 120 or 300. TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup Cc: D

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lucas_Werkmeister_WMDE added a comment. > Either the lag in WDQS needs to be fixed, or we need to introduce some scaling factor in Wikibase so that lag is usually under 5s like we have for the job queue. There //is// a scaling factor, the actual threshold is 5 minutes I believe (`wgWiki

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

ArthurPSmith added a comment. In T243701#5855439 , @ArielGlenn wrote: > In T243701#5855352 , @Lea_Lacroix_WMDE wrote: > >> Over the past weeks, we noticed a huge increase of content

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

ArielGlenn added a comment. In T243701#5855352 , @Lea_Lacroix_WMDE wrote: > Over the past weeks, we noticed a huge increase of content in Wikidata. Maybe that's something worth looking at? Wikidata content is growing at a fast and s

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lea_Lacroix_WMDE added a comment. Over the past weeks, we noticed a huge increase of content in Wikidata. Maybe that's something worth looking at? TASK DETAIL https://phabricator.wikimedia.org/T243701 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ T

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

ArthurPSmith added a comment. @Addshore and others - the problem has deteriorated since Saturday - see this discussion on Wikidata: https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Query_Service_and_search#WDQS_lag TASK DETAIL https://phabricator.wikimedia.org/T243701 E

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Strainu added a comment. In T243701#5834731 , @Addshore wrote: > Should tests be using the production api and site? > What are these tests doing? Please don't limit this to just tests. It is affecting normal, community-approved bo

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Addshore added a comment. Its starting to feel like we should just create a better mechanism for this instead of using maxlag. Per what I said in T240442#5815397 it might be nice to have wikibase / mediawiki tell a client how long to perh

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Lucas_Werkmeister_WMDE added a comment. I wonder if it would make sense to ignore query service lag on GET requests? Those requests shouldn’t put any kind of load on the query service, after all. (On the other hand, that might make certain problems annoyingly difficult to debug, if the l

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Dvorapa added a comment. > For the specific issue you are facing, I may be suggest to review SLA expectations about the api (any of it)- and timing out and erroring quickly rather than waiting in case of lag for non-interactive tests. Yeah, there are two options: either make them fail ea

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Dvorapa added a comment. > What are these tests doing? They are obviously testing Pywikibot functions against several wikiproject APIs. WD API is usually asked for simple things like some maintenance category/template fro some language. Which takes 300s+ to response last weeks randomly

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

jcrespo added a comment. > API maxlag has been repeatedly declared to always be <5s by several people in the past That would sound about right for Mediawiki API (5-10 seconds) ... > If WDQS lag is high, API maxlag is also high ... but this sounds worrying if true- I would wait f

[Wikidata-bugs] [Maniphest] [Commented On] T243701: Wikidata maxlag repeatedly over 5s since Jan20, 2020 (primarily caused by the query service)

Dvorapa added a comment. (please keep in mind I don't understand the differences, all I understand is that API lag is outrageously high, probably because WDQS lag is high as those two were connected 2 months ago and since then all our tests are sometimes failing with 300s timeouts or 50min t