You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We're building a system to analyse failures, where we need to take a samples of sufficient size from failed and successful requests to find the common causes for requests to fail.
As input we have a set of trace ids, which we currently retrieve one by one through the GET /api/traces/<traceID> endpoint.
This takes some time, even with start and end parameters set. In our setup, older traces already moved to the back end storage take anywhere from 400 to 1000ms.
Since all traces are in the same time window, an endpoint that would allow us to get multiple traces at once could probably be much more efficient.
Describe the solution you'd like
An endpoint that accepts a list of trace ids instead of a single trace id and returns all found traces in one response.
Describe alternatives you've considered
We're currently retrieving them in parallel, but this doesn't seem to scale beyond a speedup of around 4-5x.
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We're building a system to analyse failures, where we need to take a samples of sufficient size from failed and successful requests to find the common causes for requests to fail.
As input we have a set of trace ids, which we currently retrieve one by one through the
GET /api/traces/<traceID>
endpoint.This takes some time, even with
start
andend
parameters set. In our setup, older traces already moved to the back end storage take anywhere from 400 to 1000ms.Since all traces are in the same time window, an endpoint that would allow us to get multiple traces at once could probably be much more efficient.
Describe the solution you'd like
An endpoint that accepts a list of trace ids instead of a single trace id and returns all found traces in one response.
Describe alternatives you've considered
We're currently retrieving them in parallel, but this doesn't seem to scale beyond a speedup of around 4-5x.
Additional context
The text was updated successfully, but these errors were encountered: