Topic on Talk:Contributors/Projects/Editing performance

I'be been checking the new instrumentation. I assume the values being used come from the t= value in backend-timing:"D=###### t=################".

At the moment I'm assuming that the start time is being taken from the first request: https://en.wikipedia.org/wiki/PAGENAME?action=edit. The part I'm particularly unsure about is which request is being used for the final timestamp. The most obvious candidate is the https://en.wikipedia.org/wiki/PAGENAME?action=edit#null request. That is usually the final request. However I find that I can start working in the wikitext editor a lot faster than that. It seems very possible you're taking the final timestamp from a different request. If so, which one should I be using?

backend-timing is an unrelated measurement.  It shows how long it took the servers to produce the page.

The measurement used for this report is browser time, not server time.  

You can see a similar, but not identical, measurement automatically reported at the dashboard for VisualEditor total load time (VisualEditor only).  Over the course of thousands of edits, it looks like the median is running around two and a half seconds.

Unless the Grafana dashboard you linked has been changed to a completely different system, the data there is garbage. Around a yearish ago I did extensive testing, both local testing and testing with dedicated online website test systems. Actual VE load times were almost double what is being reported by the software.

If backend-timing is unrelated, could you please identify the name or location of the value that is being used? I should be able to find them in the browser network logs, with a reasonable pointer of where or what to look for.

As I said, the data for this report:

1. is not what is in that Grafana dashboard, and
2. is what the user's browser self-reports.

I believe that it uses "performance.now", but I don't know any of the details.

I'm afraid you won't find these values in the network logs. They are not directly related to when we load things.

If you really want to watch network logs, look for URLs starting with "https://en.wikipedia.org/beacon/event" (adjust the domain if you're testing on a different wiki), as that is how this data is logged. The data is in the query parameters, as JSON; https://meta.wikimedia.org/wiki/Schema:Edit has a brief description of the format. The actions "init", "ready" and "loaded" correspond to start time, time to interactive and time to fully loaded in this document.

Note that these are only recorded for 1 out of every 16 edit sessions (on average, randomly selected).

Thanks @Matma Rex. Unfortunately I can't seem to find anything going to like that URL, or anything similar. I tried many dozens of editor-loads, so even if it's only sent 1/16 I should have had a statistical certainty to catch it. I also installed an extra extension to ensure I was catching and searching all browser requests. Can you give me any additional help in capturing these values?

I'm experiencing a 70+ second load time before the 2017Editor becomes responsive, for the article en:List_of_members_of_the_Lok_Sabha_(1952–present). It's not a network speed issue, it's CPU bound. I would like to verify that the timing is actually reporting 70+ seconds. The timing would be grossly wrong if it's measured before the overloaded CPU frees up.

It works for me. The thing about randomness is that it may never happen even if you try it infinitely many times… Or maybe you have them blocked with AdBlock or something? I recommend trying with a more convenient, shorter page, until you know for sure how to capture them.

I was just able to see the following requests being made after refreshing the page https://en.wikipedia.org/wiki/Nico_Verlaan?veaction=editsource a few times:

https://en.wikipedia.org/beacon/event?%7B%22event%22%3A%7B%22version%22%3A1%2C%22action%22%3A%22init%22%2C%22editor%22%3A%22wikitext-2017%22%2C%22platform%22%3A%22other%22%2C%22integration%22%3A%22page%22%2C%22page.id%22%3A23690117%2C%22page.title%22%3A%22Nico_Verlaan%22%2C%22page.ns%22%3A0%2C%22page.revid%22%3A716846292%2C%22editingSessionId%22%3A%220f853d16be975303%22%2C%22user.id%22%3A6423215%2C%22user.editCount%22%3A1269%2C%22mediawiki.version%22%3A%221.31.0-wmf.24%22%2C%22action.init.type%22%3A%22page%22%2C%22action.init.mechanism%22%3A%22url%22%2C%22action.init.timing%22%3A422%7D%2C%22revision%22%3A17541122%2C%22schema%22%3A%22Edit%22%2C%22webHost%22%3A%22en.wikipedia.org%22%2C%22wiki%22%3A%22enwiki%22%7D;

https://en.wikipedia.org/beacon/event?%7B%22event%22%3A%7B%22version%22%3A1%2C%22action%22%3A%22ready%22%2C%22editor%22%3A%22wikitext-2017%22%2C%22platform%22%3A%22other%22%2C%22integration%22%3A%22page%22%2C%22page.id%22%3A23690117%2C%22page.title%22%3A%22Nico_Verlaan%22%2C%22page.ns%22%3A0%2C%22page.revid%22%3A716846292%2C%22editingSessionId%22%3A%220f853d16be975303%22%2C%22user.id%22%3A6423215%2C%22user.editCount%22%3A1269%2C%22mediawiki.version%22%3A%221.31.0-wmf.24%22%2C%22action.ready.timing%22%3A460%7D%2C%22revision%22%3A17541122%2C%22schema%22%3A%22Edit%22%2C%22webHost%22%3A%22en.wikipedia.org%22%2C%22wiki%22%3A%22enwiki%22%7D;

https://en.wikipedia.org/beacon/event?%7B%22event%22%3A%7B%22version%22%3A1%2C%22action%22%3A%22loaded%22%2C%22editor%22%3A%22wikitext-2017%22%2C%22platform%22%3A%22desktop%22%2C%22integration%22%3A%22page%22%2C%22page.id%22%3A23690117%2C%22page.title%22%3A%22Nico_Verlaan%22%2C%22page.ns%22%3A0%2C%22page.revid%22%3A716846292%2C%22editingSessionId%22%3A%220f853d16be975303%22%2C%22user.id%22%3A6423215%2C%22user.editCount%22%3A1269%2C%22mediawiki.version%22%3A%221.31.0-wmf.24%22%2C%22action.loaded.timing%22%3A943%7D%2C%22revision%22%3A17541122%2C%22schema%22%3A%22Edit%22%2C%22webHost%22%3A%22en.wikipedia.org%22%2C%22wiki%22%3A%22enwiki%22%7D;

After URI-decoding you can find the following information in JSON data:

• "action.init.timing": 422
• "action.ready.timing": 460
• "action.loaded.timing": 943

I will not be spending my time finding out exactly how slow "List of members of the Lok Sabha (1952–present)" is, I can see it's definitely slow.

I've been working on something entirely unrelated today and discovered that these requests are not sent if you have Do Not Track turned on in your browser – that might be the reason why you're not seeing them.

Ouch. After your previous comment I opened over four hundred article-edit tabs trying to get it to show up - bringing the odds of statistical failure to somewhere around one in a trillion. That's not counting my earlier efforts.

When I turned off DoNotTrack the values appeared almost immediately. Thanks.