-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make gcping
and gcping.com use the same method to calculate latency
#27
Comments
gcping
and gcping.com differ by factor of 2
gcping
and gcping.com differ by factor of 2gcping
and gcping.com differ by factor of ~2
The differences between the CLI and the webapp should be much smaller now. However, the webapp and the CLI use different methods to calculate latency. We should change it so they both use the same method. The webapp sends requests to the backend for 30 seconds and then takes the median for each region. The CLI just sends 10 requests (although it's configurable) before taking the median. |
gcping
and gcping.com differ by factor of ~2gcping
and gcping.com use the same method to calculate latency
Taking some notes: Web VersionFor 30 seconds, send pings on loop. Once 20 pings have occurred, shift old pings out, keeping the latest 20. Always toss out the first request to avoid reading cold start. Time Measured is from the start of the request to the time response is read. CLI VersionFor all regions make 10 requests. makes request, reads status code. Doesn't reject first request time As for requests, they both await a response. There is a small amount possibly more for the js due to reading the body, but I added that to the go impl and it made a negligible difference in timing. It is important to remember the most valid way to use this is for relative timing. There are likely optimisations that could be made to lessen the overall time, but as they all use the same backend the measurement is valid for the purpose of gcping. |
Checking in here as I opened #55. This is what you can measure with the web api. |
This seems like a great idea both for the web app and the CLI. And I agree, the difference is probably negligible. |
It looks like this tool reports the mean time for a network roundtrip, whereas gcping.com reports the one-way latency. That's a bit confusing..
I have no strong opinion what is better, but it would be nice to mention this difference. Alternatively, the tool and website could align their measurement methods.
The text was updated successfully, but these errors were encountered: