Re: [Wikidata-l] Memcached traffic
Ori, Thanks for the heads up. Can you please confirm that the problem here is not the number of requests to memcached, but the traffic volumne caused by the rather large sitelist blob? Can you tell us what the effective (compressed) size is you see in the replied from memcached? We are currently trying to reduce the cases is which we hit memcached for the sitelist, but perhaps it would also be helpful to chop that list into smaller pieces. We rarely need all of it. Thanks Daniel PS: please note that wikidata-tech is the preferred list for discussing nitty gritty tech stuff, wikidata-l is (now mostly) about project contents and policy. Am 06.09.2014 02:25, schrieb Ori Livneh: In November of last year, Aaron noticed a spike in memcached traffic, which we were eventually able to attribute to Wikibase client fetching the SiteList on every request. When Katie fixed it, outbound memcached traffic nearly halved. We're now back to the same rate of outbound traffic as then, and the culprit appears to be the same key. See: http://i.imgur.com/v9ebld6.png Tracked in https://bugzilla.wikimedia.org/show_bug.cgi?id=56602 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Memcached traffic
On Sat, Sep 6, 2014 at 2:25 AM, Ori Livneh o...@wikimedia.org wrote: In November of last year, Aaron noticed a spike in memcached traffic, which we were eventually able to attribute to Wikibase client fetching the SiteList on every request. When Katie fixed it, outbound memcached traffic nearly halved. We're now back to the same rate of outbound traffic as then, and the culprit appears to be the same key. See: http://i.imgur.com/v9ebld6.png Tracked in https://bugzilla.wikimedia.org/show_bug.cgi?id=56602 I can see two reasons for this: 1) the other projects sidebar beta feature, which we have realized needs improvement in how / where things are cached. https://gerrit.wikimedia.org/r/#/c/157500/ - plan to backport on Monday https://gerrit.wikimedia.org/r/#/c/158381/ - perhaps can wait (?) until next regular scheduled deployment of wikibase, not this week but following week 2) the way badges are handled in the sidebar. This doesn't look like as simple of a fix but looking at options for this and sure we can find a solution. Cheers, Katie ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Katie Filbert Wikidata Developer Wikimedia Germany e.V. | Tempelhofer Ufer 23-24, 10963 Berlin Phone (030) 219 158 26-0 http://wikimedia.de Wikimedia Germany - Society for the Promotion of free knowledge eV Entered in the register of Amtsgericht Berlin-Charlottenburg under the number 23 855 as recognized as charitable by the Inland Revenue for corporations I Berlin, tax number 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Memcached traffic
In November of last year, Aaron noticed a spike in memcached traffic, which we were eventually able to attribute to Wikibase client fetching the SiteList on every request. When Katie fixed it, outbound memcached traffic nearly halved. We're now back to the same rate of outbound traffic as then, and the culprit appears to be the same key. See: http://i.imgur.com/v9ebld6.png Tracked in https://bugzilla.wikimedia.org/show_bug.cgi?id=56602 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
