Thanks for the write up. It doesn't seem like we're missing anything other than performance regression tracking 👍
On Fri, Jul 24, 2015 at 1:51 AM, Jon Robson <jrob...@wikimedia.org> wrote: > The reading team are currently focusing energy on speeding up the site > for all our users (https://phabricator.wikimedia.org/T98986 is the > tracking bug where this work can be followed) > > Off the back of https://phabricator.wikimedia.org/T105361 I had a > quick chat with Ori to document how the performance team is currently > identifying problems with MediaWiki's code. I'm sharing here, so > anyone who is interested in helping us improve the time our users can > load our content can analyse our data, raise tasks, and submit > patches. > > I'm hoping this will be useful for anyone who wants to get involved in > an effort to make our site faster for our users (this is not desktop > specific). If you have anything useful to add please do, after some > discussion or nods I'd love to share some best practices on > mediawiki.org > > Tool 1) Use http://webpagetest.org (no credentials necessary) > * Use https://en.wikipedia.org/wiki/Facebook as an example wiki page > * Choose a region of the world and browser > * Select first view only since this is what we are currently > interested in (repeat view is when they load again - and it should be > quicker as it is from cache). > * Capture video can be turned off - I personally find the screenshots > more useful > > To shout out some of the advanced settings, the more > interesting/useful features include: > *Chrome > capture dev tools timeline > * Setting speed 3G or 2G > * Script can be used to conditionally turn on things which are not yet > available to everyone e.g. VisualEditor > > You can do a lot of this in your Chrome browser locally, but different > browsers may have different behaviours and are in a fixed location so > this does not get captured in this tool. The visual screenshots also > make it easier to see where things get blocked. With the timeline from > advanced tools you can match up white screens with blocking > scripts/styles > > Tool 2) Add http://performance.wikimedia.org to your browser > bookmarks. Navigation timing section is probably the most interesting > right now. It points to https://grafana.wikimedia.org (no credentials > needed) which is powered by http://graphite.wikimedia.org (Access > graphite with your wikitech credentials). This data is sourced from > our users, so is a good representation of how we are doing. > > If a graph is missing you can create a new one from data in graphite > by clicking "add row" or editing an existing graph. > > Clicking edit on > > https://grafana.wikimedia.org/#/dashboard/db/navigation-timing?panelId=12&fullscreen&edit > you'll be able to understand where the data comes from on graphite > e.g. metrics/frontend/navtiming/totalPageLoadTime > Note for graphs median data is less sensitive to edge cases so best to > use this as a more realistic indicator. > > Folders in graphite, are populated by scripts that live in: > > https://github.com/wikimedia/operations-puppet/tree/production/modules/webperf/files > > To create a graph, simply go to an existing workboard, save it under a > different name (this clones it) - don't worry you can't mess up and > delete existing workboards. > > Tool 3) Speedcurve requires you to setup an account but it gives you > an opiniated view about things you care about and is nicely presented > so could be a good source of inspiration for your own grafana > dashboard. > > To oversimplify what it does: each day it will access a page, store > result, allow you to see historic data. > Note the performance team has plans to setup infrastructure to automate > this. > > Tool 4) is one we are not using - http://sitespeed.io. We might want > to use it for performance regressions test. > > In the grand scheme of things it would be great to get to a place > where Jenkins complains if you cause a regression in firstPaint time > but we are a long way from that but let's work in that direction :-) > > Let's live up to the Hawaiian word after which we are named! > Apologies if this is oversimplified, please take this as an > opportunity to share how you/your team/your company test page > performance. I see this mailing list as a good place to share these > sort of things! > > _______________________________________________ > Mobile-l mailing list > mobil...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
