High latency (~1 min): known issue?

[jmitchell]

On multiple occasions pages at https://mirago.io took as long as 30 to 90 seconds to load. According to a trace in Wireshark there were 143/518 (27.6%) packets dropped while loading one page.

Are there known issues in Mirage or this application that would explain it? Are there server-side analytics that could help? I realize there are a lot of potential explanations, and many are outside Mirage's control. For what it's worth I'm using a reliable broadband connection in Seattle. I rarely see this behavior with other websites.

[avsm]

The variability of the latency is often less than a minute, but i have observed this too. I have not got a packet trace though ...

[mato]

@jmitchell Could you upload a copy of the problematic packet trace somewhere?

[jmitchell]

Here's a screenshot of this page loaded in Chrome with the network traffic and timing logged. I intentionally disabled the cache.

I have the corresponding pcap, but would prefer not making it public unless/until I work out how to scrub it more. Alternatively, I could email it to a trusted Mirage dev or two who want to investigate.

By the way, these problems are frequent for me. Are either of you able to frequently replicate this? It's easier to tell after you clear/disable your browser cache. Occasionally pages fully load within 2-3 seconds, but very often it takes at least a minute. This is measured by when Chrome's Network tab shows "DOMContentLoaded" with elapsed time in blue. Note that "Finish: _ ms/s/min" in the status bar of the Network tab does not mean it's finished; it's updated as assets are downloaded.

[jmitchell]

You can find the CSV export of the pcap here. Notice there are a lot of TCP retransmissions.

[yomimono]

Thanks for the detailed report! We've done a lot of work on tcpip that is currently on trunk but not yet released, which means that https://mirage.io is not running it. I'll check whether this behavior persists with the latest tcpip checkout today.

[jmitchell]

Thanks for investigating, @yomimono.

[avsm]

mirage/mirage-tcpip#239 will definitely help with this due to being on the recovery path, but still need to find source of packet loss

[yomimono]

https://mirage.io has been rebuilt with tcpip version 2.8.1, which includes #239 . I wasn't able to reproduce with the new version -- @jmitchell , can you let us know one way or the other?

[jmitchell]

Load times are significantly better now, but may need more attention. Most pages are loading within 5 seconds without local browser caching. The blog is an outlier in my ad-hoc sample, frequently taking ~10 seconds to load sans cache.

Do you have a sense for the server's bottleneck now? Are response-time logs available?

[yomimono]

We've been leaving this issue open as a proxy for "better performance testing for mirage-tcpip", but I've just opened a real issue for that over at mirage/mirage-tcpip#314 . As such, I'm closing this issue. Please do continue to report performance problems as you see them; this was extremely helpful and we're grateful for your contribution, @jmitchell !