christhekeele
commented
5 years ago The main sensitive issue I forsee is sampling of timing data impacting performance of Mojito itself.
I don't think several System.monotonic_time measurements and a few System.convert_time_unit/Integer.to_string calls would make a huge difference. Plug itself
makes similar calls in its Logger.
But both Logger and Plug purge such unnecessary calls in production environments via macros, so perhaps a similar Mojito mechanism should do the same?
gamache
collegeimprovements
andyleclair
Playing around with an HTTP forward-proxy powered by Mojito. One question I keep asking myself: how much overhead am I adding?
Round trip time
The consumers of my service, of course, can sample their language equivalent of
System.monotonic_time()immediately before and after the request. I would like to provide them with a number to subtract from the result to understand the overhead.Proxy spent time
My proxy could sample the same, right after receiving and right before returning the response for, the proxied request.
Proxy waiting time
It could also figure out how long requests took outside of its own logic via the same mechanism, by tightly wrapping Mojito calls in timing measurements.
External waiting time
The main metric I am interested in that I cannot obtain is how long Mojito itself spent waiting for the upstream to respond.
I would like to return the time spent outside the proxy to the caller, but I can't do this without knowing how long Mojito itself was blocked, since I want to incorporate time spent in Mojito into the time spent in the proxy, and separate it (as much as possible) from the external time spent waiting for the request to be processed.
The only way I can see this working is having Mojito aggregate the time spent waiting for connection responses from Mint, and return the sum once the request is completed to the caller of
Mojito.request.Any thoughts about how this could work to guide a PR?