Magnus added a comment.
In T226084#5271761 <https://phabricator.wikimedia.org/T226084#5271761>, @Krinkle wrote: > @Magnus It is well-known currently that MediaWiki exposes many powerful API that we do not support to perform well, but allow regardless as a convenience service. If we were stricter about response times for all features, we'd probably just turn many of them off and limit the capabilities of those APIs until and unless the amount of resources required to make them work reliably fast is justified. > > I expect the maintainers of this API to have tested the supported and encouraged use cases and to know whether they are fast. I haven't personally looked at the p99 for this particular API, but from experience in other endpoints, it tends to be extreme cases that we'd be very unlikely to support with fast responses. > > But if they haven't in a while, it's certainly worth looking at those again from time to time. That's not what the issue is about. If a query usually runs 1-3sec, no problem if it takes 10, or 30 in rare cases. This issue is different because: - timing differences are extreme. 3sec vs 3min - this kind of thing is new, as in a few days ago, when it's been working fine for years - the exact same query, run again, will very likely return in the usual short time - the extremely long response makes tools unusable. If I'd get an error I could possibly recover, but just waiting is not easily caught - the extremely long response breaks some default settings, e.g. the one I use for my Rust tools This all points to a single point of failure, either on the response generation or on the transport. Trying to weasle out of it with "APIs are complicated" is not helpful. > Meanwhile, do let us know if you find a response with a slow value recorded in the Backend-Timing header. You can use this to see whether the time was spent on the web server or in transportation/routing. If it's in routing that still doesn't mean it's outside Wikimedia control, we do influence a lot of the routes between DCs and for ISPs/peering and BGP stuff. It just helps narrow it down. How would I "find a response with a slow value recorded in the Backend-Timing header"? I think I have posted all the data I can get from slow responses. TASK DETAIL https://phabricator.wikimedia.org/T226084 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Magnus Cc: Tgr, Krinkle, jcrespo, Addshore, alaa_wmde, Lea_Lacroix_WMDE, WMDE-leszek, Aklapper, Magnus, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
