Tue, Oct 16
Yes, this is approved.
Mon, Oct 15
Blocked on https://gerrit.wikimedia.org/r/c/operations/puppet/+/465538 - @BBlack @ema would one of you be able to help me out?
Thu, Oct 11
Wed, Oct 10
Responding to a question that someone (I had the etherpad active and so couldn't see who was speaking) asked today during SoS: We don't have any current plans to work on T176262 -- it's in our backlog, but isn't something that we've chosen to allocate time to working on to this point.
Tue, Oct 9
Need SRE to grant me Google Search Console access in order to move forward with this.
@phuedx - Only in part. Mikhail did a very detailed analysis, based in part on the data that Nuria mentioned there.
Fri, Oct 5
Awesome -- speak up if there's anything that the rest of us can do to help!
Do you have an adblocker or similar installed in Firefox, by any chance? The fact that this does not occur in Chrome makes it almost certain that this is browser configuration related.
Thu, Oct 4
Peter, did you modify our private instance to address this? I just took a look through wpt.wmftest.org and I'm not seeing anything loading from an external domain, including on the results pages.
Wed, Oct 3
Physical latency seems almost certain to be the issue. It's 36ms roundtrip from codfw to eqiad, so the tolerance is quite tight.
Tue, Oct 2
Activated and verified in beta.
Mon, Oct 1
@aaron - Please take a look and speak up if there's obvious ways to refactor/address this.
Tue, Sep 25
Note: I suspect that this is going to result in the canonical link tag being doubled up. Easy fix if so.
Focus for addressing this should be here, I think: https://github.com/wikimedia/mediawiki/blob/master/includes/cache/MessageCache.php#L528-L544
Analysis at https://phabricator.wikimedia.org/T203925#4616856 suggests that the issue is that every single content revision is being pulled individually from the cache. Even when memcache returns quickly (500us), in some instances we're making tens of thousands of independent calls to memcache and they're adding up. It looks like maybe some sort of batching in MessageCache::getFromDB is called for, but I haven't really deep-dived.
Wrapped @AndyRussG's example above in xhprof, just running in shell:
Mon, Sep 24
From our June offsite:
2 c4.large instances and one c4.xlarge instance are around $300/month -- that's significantly less than what we have budgeted for AWS, so no issue at all.
Sep 19 2018
I haven't thought through the ideal way to do this, but what about adding an additional test for a very simple page -- like a page that just loads a single image or something, maybe even from a file:/// URL. I'd be curious to see whether that returned consistent values, and/or whether there was a difference in the amount of variation between browsers.
Sep 18 2018
Simply noting that if we were to do this, it would be ideal for device detection to be based on CSS selectors. Google and others use CSS selectors, provided as the media attribute of a <link rel="alternate"> tag, to decide whether to direct users to the desktop or mobile version of a site when they're served from different URLs.
@Peter you pretty much said what was in my notes :-)
@kaldari The >500,000 number is based on Google Search Console, which provides us with the number of valid pages that they know about within the domain. On July 5th, 2018, Google had indexed 2,603,000 valid pages on the domain it.wikipedia.org. On July 10th, 2018, they reported that they had indexed 1,813,000 valid pages.
@Nemo_bis Regarding your comment above, about Google not respecting canonical URLs: it's not that they don't respect them, it's that we're not currently giving them the type of hints that they want specifically for mobile discovery.
Sep 17 2018
@AndyRussG Perf team will keep an eye on this, but please give us a shout if there's help needed here.
@daniel Is this possibly related to changes that you've been making?
This should definitely be fixed before 1.32.
Verified that generateSitemap.php is now outputting with fully qualified paths: