Replaced stopwatch with a shared-stopwatch suitable for sharing between go routines#273
Conversation
…en go routines. Fixed discovery timing metrics. Fixed json encoding of discovery metrics.
|
Apologies, taking me a while to get to this. |
|
No rush, the stopwatch is not clicking... yet :P |
shlomi-noach
left a comment
There was a problem hiding this comment.
I'm just wondering here what is the meaning of summing up the latencies where some of the operations run in parallel?
The sum of latencies is a metric, but does not depict overall run time, which may be smaller than the sum.
|
So, it is not recording the sum of the latencies, but indeed the overall run time from the app point of view. Another way to see it is: if you have N workers in your house, the stopwatch measures "how long did they take to put the floor", not "how many man-hours did it took to put the floor". |
|
Thank you for clarifying! |
|
Friendly ping. |
|
Naughty @sjmudd . I asked him to relay that I will be busy finalizing a release of orchestrator (As I did yesterday) and will only then proceed to address Booking.com's PRs, as well as deliver my apologies for the delay. |
|
I'm going to merge this into a local branch called "shared-stopwatch", and test it in production for a while. |
|
By the way, @maurosr I encourage you to not work on your |
This PR fixes the discovery timing metrics.
Also fixes an issue with the json encoding of discovery metrics.
This shared stopwatch can be shared between multiple go routines. It will record elapsed real time, i.e. all time where at least one routine was doing a certain task. For example, if routine1 started work at 07:00:01 and ended at 07:00:06, routine2 started work at 07:00:03 and ended at 07:00:09 then elapsed time will be 8s.