Should the latency measurements include the results from unsuccessful queries? #56
DenhamPreen
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
👋 Introduced myself here
In doing some initial exploring of flood it looks like the latency metrics include unsuccessful queries too which don't allow for apples-to-apples latency comparisons. The behavior I was expecting was that if a request was unsuccessful then it wouldn't be included in the latency.
Here is the request and summary that leads me to this understanding.
The findings from the above are that ankr was completely unsuccessful (maybe down, maybe rate limited from a prior req), thus I assume the [p90 vs load] results are based on the latency of the unsuccessful requests.
Knowing that the ankr requests had a 0% success rate I can safely ignore the latency results however for the llama rpc tests at a rate of 100 rps the success rate was only 5.2% and the latency 0.309 s, leading me to think the llama rpc was much faster however I think this metric is skewed by the fact that unsuccessful requests have a much smaller latency than successful requests.
The discussion point I'm opening is on whether the latency measurements should only include successful requests. I would say the results of [p90 vs load] in isolation are not a good representative of the latency as you can't compare in relation to other rpc's without them having the same success rates.
Additional context: I am running via docker, testing against free RPC endpoints sourced from chainlist
Beta Was this translation helpful? Give feedback.
All reactions