I think we should try the non-smart version for a bit (serving the link no matter what, even for articles without images) and look at the effect in the wild.
Tue, Jan 21
Thu, Jan 9
Wed, Jan 8
I approve this request 🦄
Tue, Jan 7
I presume the googlebot that looks for metadata errors just happened to randomly discover that page. Anyway, thanks for fixing this!
I left a comment on the talk page: https://ar.wikipedia.org/wiki/%D9%86%D9%82%D8%A7%D8%B4:%D8%A8%D8%B7%D9%88%D9%84%D8%A9_%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%85_%D9%84%D9%83%D8%B1%D8%A9_%D8%A7%D9%84%D9%82%D8%AF%D9%85_%D8%AF%D8%A7%D8%AE%D9%84_%D8%A7%D9%84%D8%B5%D8%A7%D9%84%D8%A7%D8%AA_2008#This_article_contains_dates_and_text_in_Thai
Actually, this is very on topic! It made me realise that 2551 is the Thai calendar year, the islamic calendar is actually behind, it should be 1428. 2008 in Gregorian.
Mon, Jan 6
Please bump/reset priority once the task is filled out
@jijiki as far as I can tell, this was never roll-deployed?
@alanajjar Is it common for arwiki articles like this one to use the islamic calendar? I see at the bottom that the categories are Gregorian years. The issue would certainly go away if those dates were converted to Gregorian years in the affected article. The error Google reported is only for that article, but I see no edits on December 26. Maybe a template changed?
Dec 20 2019
In a brilliant move, I have already forgotten which password I set and did not write it down. What's the procedure to initiate a password reset?
It's ResourceLoader loading a bunch of CSS.
Dec 19 2019
Since the migration work is starting in Q3, it sounds like this task would be obsolete at some point in 2020, right? I guess as part of the migration it would be nice to make it a requirement to get rid of those headers being sent to end users, granted that ATS is capable of doing that.
Dec 17 2019
I would like to retain my ability to access Hadoop from the stat* hosts 🙃 My shell name is gilles
Dec 16 2019
Body of the template coming later in the quarter, I assume?
Yep, here's an example for 3: https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/504501/
Dec 13 2019
Yeah, that works
Yeah the origin trial token header can act as the feature flag for something like this. Just tripled check that this doesn't break anything on a browser that doesn't support this feature.
Did you make sure that the jsfiddle page was already loaded and pressed "run" on there? Otherwise when the benchmark runs during the full pageload I think the iframe competes too much with the rest and the scores are much higher.
I've just received the Motorola phone and it feels pretty fast (of course it's pretty empty since I've just set it up).
Fantastic, thank you very much!
Dec 12 2019
Are those all happening on requests that are timing out (and killed as a result)?
Dec 11 2019
@Krinkle do you mean that every time these fatals occured, the request had an excimer sample happen?
Dec 10 2019
Thinking a bit more about the connectivity cap issue, it actually doesn't matter for percentiles. Because anything capped at 10 would have been higher. I had also made the mistake of looking at p75 for downlink, when I needed to look at p25 (because lower is worse for downlink, unlike the benchmark score and rtt). Here are the updated figures:
@ema what's the current state or plan for this in ATS?
Looking at the version of PHP 7 we're running, this error shows up a few times. The condition for it is always the same:
Ordered, second hand. I couldn't get exactly the same specs for the Motorola, the non-US version is under-clocked (same processor, though). But I don't expect that to be a problem. Next step when I receive the phones is to add or remove junk on them until I get benchmark scores that are close to the target.
Now, microbenchmark scores.
SELECT event.originCountry, PERCENTILE(event.netinfoRtt, 0.75) AS rtt_p75, PERCENTILE(event.netinfoRtt, 0.95) AS rtt_p95, PERCENTILE(event.netinfoRtt, 0.99) AS rtt_p99, FLOAT(PERCENTILE(BIGINT(event.netinfoDownlink * 100), 0.75)) / 100.0 AS downlink_p75, FLOAT(PERCENTILE(BIGINT(event.netinfoDownlink * 100), 0.95)) / 100.0 AS downlink_p95, FLOAT(PERCENTILE(BIGINT(event.netinfoDownlink * 100), 0.99)) / 100.0 AS downlink_p99, COUNT(*) AS sample_size FROM event.navigationtiming WHERE year = 2019 AND month = 11 AND event.originCountry IN ('IN', 'US') AND event.netinfoRtt IS NOT NULL AND event.netinfoDownlink IS NOT NULL AND event.mobileMode = 'stable' GROUP BY event.originCountry;
Dec 9 2019
I've done the minimal sanity check of frontend payload and see that the newly introduced RL module is correctly only loaded on the special page, making this very low-risk in terms of site-wide frontend performance regression. The feature itself on the special might have possible improvements, which I'll let @Krinkle look into, but this can roll out as-is.
We're still seeing an extra 100-150ms on the p75 TTFB reported by clients in Europe compared to before 11/11. Only 20ms of which can be attributed to TLS.