Re: [Wikitech-l] [Engineering] Update from the Perf Team

[Brad Jorsch (Anomie)]

On Sun, May 29, 2016 at 2:22 PM, Gergo Tisza  wrote:

> Fetching all thumbnail URLs in a single request is T56037
>  and should not be particularly
> complicated.


Well, T56037 is blocked by T56035, and the current plan for dealing with
that is T66214.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Update from the Perf Team

[Brion Vibber]

On Saturday, May 28, 2016, Brian Wolff  wrote:

> Pages with large number of thumbnails tends to be a slow path in the
> parser. This is even more true for people using instant commons. I dont
> know for sure, but I imagine it could be improved by batching the checks
> for finding image width/height (that might be a difficult change to make
> though).


Batching requests sounds possible but would need to retool some things. The
good news is the file links should all be visible in the expanded
preprocessor DOM, so it should be possible to walk the tree, make a
list, batch the file lookup requests and then pass the batch cache into the
Linker functions.

Uh, that's assuming I'm not misremembering the order of operations with
respect to template expansion. :)


IIRC, InstantCommons is slightly trickier as you also need to make multiple
API calls to fetch thumbnail URLs, made even worse by needing to fetch
multiple resolutions for srcset. This gets real nasty if there are a lot of
files and the thumbnail ref data isn't cached...

We could change all that if there was a stable enough URL/linking
API... Can probably fake it for common cases and supported handlers by
generating a URL like we would for a local 404-handler repo; my main
concern is for future expansion where we add more fancy types on Commons
where the local site may not have an extension installed locally. (Iframe
embedding as a fallback for unknown handlers sounds possible, could expose
a frame URL in the imageinfo data.)

-- brion


>
> --
> Bawolff
>
> On Saturday, May 28, 2016, Pine W >
> wrote:
> > Thank you for the update. FWIW, a page that I load frequently that takes
> a
> > long time is Commons' featured picture candidates. My guess is that
> > starting with the implementation of HHVM and with smaller improvements
> > thereafter, the page load time had been reduced by more than 50%, which
> is
> > impressive and much appreciated.
> >
> > Pine
> > On May 27, 2016 15:28, "Ori Livneh" >
> wrote:
> >
> >> Hello,
> >>
> >> Here's what the performance team has been up to.
> >>
> >> == Dashboards & instrumentation ==
> >> We spent time instrumenting software and curating displays of
> performance
> >> data. We have several new dashboards to share with you:
> >>
> >> * Global edit rate and save failures (new)
> >>   https://grafana.wikimedia.org/dashboard/db/edit-count
> >>
> >> * Performance metrics (revamped)
> >>   https://grafana-admin.wikimedia.org/dashboard/db/performance-metrics
> >>
> >> * Page load performance
> >>   https://grafana.wikimedia.org/dashboard/db/navigation-timing
> >>
> >>   ...by continent:
> >>
> https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-continent
> >>   ...by country  :
> >>
> https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-geolocation
> >>   ...by browser  :
> >> https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-browser
> >>
> >> * We found that certain browsers were reporting wildly inaccurate timing
> >> data and skewing our summary performance metrics, and reacted by
> validating
> >> browser metric data more strictly against Navigation Timing API specs.
> >>
> >>
> >> == ResourceLoader ==
> >> ResourceLoader is the MediaWiki subsystem responsible for loading CSS,
> >> JavaScript, and i18n interface messages for dynamic site features. It is
> >> critical to site performance. Changes to ResourceLoader are focused on
> >> reducing backend response time, ensuring we make efficient use of the
> >> browser cache, and reducing time to first paint (the time it takes any
> >> content to appear). This work is led by Timo Tijhof.
> >>
> >> * The "/static/$mwBranch" entry point has been deprecated and removed in
> >> favor of wmfstatic - a new multiversion-powered entrypoint accessed via
> >> "/w" (via RewriteRule)
> >>   https://phabricator.wikimedia.org/T99096
> >>
> >> * Restricting addModuleStyles() to style-only modules (ongoing)
> >>   https://phabricator.wikimedia.org/T92459
> >>
> >> * Startup module check is now based on a feature test instead of browser
> >> blacklist
> >>   https://phabricator.wikimedia.org/T102318
> >>
> >>
> >> == WebPageTest ==
> >> Page load performance varies by browser, platform, and network. To
> >> anticipate how code changes will impact page performance for readers and
> >> editors, we use WebPageTest (
> >> https://wikitech.wikimedia.org/wiki/WebPageTest),
> >> a web performance browser automation tool. WebPageTest loads pages on
> >> Wikimedia wikis using real browsers and collects timing metrics. This
> work
> >> is led by Peter Hedenskog.
> >>
> >> * We now generate waterfall charts for page loads on Firefox. Previously
> we
> >> were only able to produce them with Chrome.
> >>
> >> * We tracked downs two bugs in WebPageTest that caused it to report an
> >> incorrect value for time-to-first-byte and reported them upstream.
> >>   

Re: [Wikitech-l] [Engineering] Update from the Perf Team

[Brian Wolff]

Pages with large number of thumbnails tends to be a slow path in the
parser. This is even more true for people using instant commons. I dont
know for sure, but I imagine it could be improved by batching the checks
for finding image width/height (that might be a difficult change to make
though).

--
Bawolff

On Saturday, May 28, 2016, Pine W  wrote:
> Thank you for the update. FWIW, a page that I load frequently that takes a
> long time is Commons' featured picture candidates. My guess is that
> starting with the implementation of HHVM and with smaller improvements
> thereafter, the page load time had been reduced by more than 50%, which is
> impressive and much appreciated.
>
> Pine
> On May 27, 2016 15:28, "Ori Livneh"  wrote:
>
>> Hello,
>>
>> Here's what the performance team has been up to.
>>
>> == Dashboards & instrumentation ==
>> We spent time instrumenting software and curating displays of performance
>> data. We have several new dashboards to share with you:
>>
>> * Global edit rate and save failures (new)
>>   https://grafana.wikimedia.org/dashboard/db/edit-count
>>
>> * Performance metrics (revamped)
>>   https://grafana-admin.wikimedia.org/dashboard/db/performance-metrics
>>
>> * Page load performance
>>   https://grafana.wikimedia.org/dashboard/db/navigation-timing
>>
>>   ...by continent:
>> https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-continent
>>   ...by country  :
>>
https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-geolocation
>>   ...by browser  :
>> https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-browser
>>
>> * We found that certain browsers were reporting wildly inaccurate timing
>> data and skewing our summary performance metrics, and reacted by
validating
>> browser metric data more strictly against Navigation Timing API specs.
>>
>>
>> == ResourceLoader ==
>> ResourceLoader is the MediaWiki subsystem responsible for loading CSS,
>> JavaScript, and i18n interface messages for dynamic site features. It is
>> critical to site performance. Changes to ResourceLoader are focused on
>> reducing backend response time, ensuring we make efficient use of the
>> browser cache, and reducing time to first paint (the time it takes any
>> content to appear). This work is led by Timo Tijhof.
>>
>> * The "/static/$mwBranch" entry point has been deprecated and removed in
>> favor of wmfstatic - a new multiversion-powered entrypoint accessed via
>> "/w" (via RewriteRule)
>>   https://phabricator.wikimedia.org/T99096
>>
>> * Restricting addModuleStyles() to style-only modules (ongoing)
>>   https://phabricator.wikimedia.org/T92459
>>
>> * Startup module check is now based on a feature test instead of browser
>> blacklist
>>   https://phabricator.wikimedia.org/T102318
>>
>>
>> == WebPageTest ==
>> Page load performance varies by browser, platform, and network. To
>> anticipate how code changes will impact page performance for readers and
>> editors, we use WebPageTest (
>> https://wikitech.wikimedia.org/wiki/WebPageTest),
>> a web performance browser automation tool. WebPageTest loads pages on
>> Wikimedia wikis using real browsers and collects timing metrics. This
work
>> is led by Peter Hedenskog.
>>
>> * We now generate waterfall charts for page loads on Firefox. Previously
we
>> were only able to produce them with Chrome.
>>
>> * We tracked downs two bugs in WebPageTest that caused it to report an
>> incorrect value for time-to-first-byte and reported them upstream.
>>   https://phabricator.wikimedia.org/T130182
>>   https://phabricator.wikimedia.org/T129735
>>
>> * We upgraded the WebPageTest agent instance after observing variability
in
>> measurements when the agent is under load.
>>   https://phabricator.wikimedia.org/T135985
>>
>> * We designed a new dashboard to help us spot performance regressions
>>   https://grafana.wikimedia.org/dashboard/db/webpagetest
>>
>>
>> == Databases ==
>> The major effort in backend performance has been to reduce replication
lag.
>> Replication lag occurs when a slave database is not able to reflect
changes
>> on the master database quickly enough and falls behind. Aaron Schulz set
>> out to bring peak replication lag down from ten seconds to below five, by
>> identifying problematic query patterns and rewriting them to be more
>> efficient. We are very close to hitting that target: replication lag is
>> almost entirely below five seconds on all clusters.
>>
>> https://phabricator.wikimedia.org/T95501
>>
>> * High lag on databases used to generate special pages no longer stops
job
>> queue processing
>>   https://phabricator.wikimedia.org/T135809
>>
>> == Multi-DC ==
>> "Multi-DC" refers to ongoing work to make it possible to serve reads
from a
>> secondary data center. Having MediaWiki running and serving requests in
>> more than one data center will reduce latency and improve site
reliability.
>> This project is led by Aaron Schulz.
>>
>> In order for this to be possible,