Lucas_Werkmeister_WMDE added a comment.
In T324202#9419893 <https://phabricator.wikimedia.org/T324202#9419893>, @WMDE-leszek wrote: > Finally, I'd like to address the above remarks of possibly introducing some fallback cache key generation algorithm to not change keys while changing the logic in the cache class. I'd think it would be sensible to provide some data, if it was actually intended to introduce some "smart" logic to keep cache keys unchanged. Without understanding the suggested impact it does seem like unnecessary complexity to me. I already provided some data in T324202#9302370 <https://phabricator.wikimedia.org/T324202#9302370>. A cache hit rate between 98% and 99% means that, if we remove the cache, the database will be hit with somewhere between 50× and 100× as many queries of this type as before. I don’t know how this query compares to other queries that hit the database (does it currently occupy 0.1% of the execution time? 1%? 10%? no idea), but it seems to run often enough to occasionally show up in the slow queries log <https://logstash.wikimedia.org/app/dashboards#/view/43fcccd0-4df5-11ec-81e9-e1226573bad4> (searching for `wbt_term_in_lang`, a table name that I expect to appear in the database query underlying this cache) – the few instances where this query was above the threshold to get logged (5 seconds) already sum to 47.4 s in the past hour. > I'd naively think if such a detail like changing the cache key generation algorithm (I guess equaling temporary dropping of cache) can take Wikidata down, we might have bigger problems than what is being discussed here. I admit I don't remember details of rollout of the cache approach (instead of the secondary SQL table) but I don't recall any spectacular outages on the way. I don’t understand this argument. The cache was considered necessary when we introduced it (T242871 <https://phabricator.wikimedia.org/T242871>), and while the site wasn’t down before then, the cache improved performance substantially (e.g. median parse time for Wikibase items halved, from ~200 ms to ~100 ms, T242871#6625282 <https://phabricator.wikimedia.org/T242871#6625282>). More generally speaking – how can we build a well-performing website when the very mechanisms that make it perform well can be criticized purely on the grounds that, if those mechanisms were removed, the website would no longer perform well? It’s possible the site won’t go down if we just change the cache key, but I’d rather avoid the massive load spike if we can. TASK DETAIL https://phabricator.wikimedia.org/T324202 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: WMDE-leszek, thiemowmde, Paladox, Michael, ItamarWMDE, Aklapper, Lucas_Werkmeister_WMDE, Danny_Benjafield_WMDE, Isabelladantes1983, Themindcoder, Adamm71, Jersione, Hellket777, LisafBia6531, Astuthiodit_1, malberts, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, TK-999, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Jdforrester-WMF, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
