ndt/7: Client side rate limiting

[spencerbn]

I'm implementing a simple chrome-based client to run tests on a background worker. I am using the NDT/7 servers that are hosted by m-lab. While running the download test it seems like the client is being overwhelmed by the amount of messages its receiving – it's causing rendering issues and frames to be dropped even when I do no processing in the "onmessage" call.

Since Websocket doesn't seem to have any sort of built-in back-pressure method, are there recommendations for handling the large amount of messages in the client? Is there an option that can be sent when initiating the test to indicate that it's a "fragile" client?

I read through the issues and didn't see anything addressing this question. However #315 seems like it could help the issue by simply stopping the test once it converges.

Please let me know if there are any recommendations for handling this. I'm really impressed with this project and grateful that all the contributors seem to work really hard to keep improving it.

[critzo]

@SpencerLawrenceBrown First, we are encouraging developers to use https://github.com/m-lab/ndt7-js/ for new ndt7 integrations, Just wanted to ensure you were aware of that since it sounds like a web client you're developing. The first-client branch will soon be merged into a first official release. Others on the team may have more to say about #315 or other issues your client is encountering.

[spencerbn]

@critzo thanks for letting me know that. I read through the code and it seems like it will suffer the same fate as my custom client since there is no feedback loop to the server. My main issue is that I am receiving so many messages the it's blocking the chrome thread and dropping frames. Seems like there isnt a solution for that currently

[critzo]

@SpencerLawrenceBrown new issues like this one are reviewed in our team sprint planning sessions, so I expect that our team will review and comment on a possible solution.

[robertodauria]

@SpencerLawrenceBrown Could you add more details on how to reproduce the issue? Did you profile it via the "Performance" tab in the developer tools? My understanding is that code running outside the main thread should not cause rendering issues / dropped frames in any case. We are actively working on the reference JS client these days (the one @critzo linked to) and if you can reproduce the issue with that one we will prioritize a fix and likely figure out why your custom client causes the main thread to slow down, too.

Since Websocket doesn't seem to have any sort of built-in back-pressure method, are there recommendations for handling the large amount of messages in the client? Is there an option that can be sent when initiating the test to indicate that it's a "fragile" client?

If you can - for example - download a file at your network speed with your browser and your hardware, with the same browser and hardware you should be able to run an ndt7 measurement without blocking the main thread. The bottleneck should always be the network speed. If we're being limited because of bugs in the code, then we definitely want to fix them. :)

Could you also say more about the network you're trying to measure (e.g. what's your expected DL/UL rate?)

[laiyi-ohlsen]

@stephen-soltesz

[laiyi-ohlsen]

@mattmathis

[stephen-soltesz]

@SpencerLawrenceBrown similar to @robertodauria's question -- can you share what the system specs are for the client machine? i.e. OS, RAM, CPU, model or year, architecture, etc, anything that might help explain what you're seeing. We've recognized that we have not yet published "recommended specs" for clients.