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
Hi,
I think I know the cause here as I reviewed the change likely causing this (I thought it wouldn't have a measurable performance impact as Sites are being loaded anyway... Seems I was wrong there). I will have another look at this soon and try to cache things on another layer so that we don't have to pull Sites that often.
Thank you for bringing this up.
Cheers,
Marius
On 5. September 2014 20:25:49 EDT, Ori Livneh ori@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
Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops
On Sat, Sep 6, 2014 at 2:25 AM, Ori Livneh ori@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
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