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
For larger queries backendRequests has a large negative impact on performance.
By placing a series of simple log messages in the RoundTrip function we can see that queries that generate a large number of backend requests are negatively impacted.
For this query we created 300k jobs, but only 3000 of them finished because the limit was satisfied. The total time was 16s but you can see that only ~2s was spent searching while ~14s was spent building the backendRequests()
Taking the same query but reducing the time range. In this case roughly the exact same number of jobs were completed successfully, but the query took significantly less time simply b/c it created fewer jobs.
For larger queries backendRequests has a large negative impact on performance.
By placing a series of simple log messages in the RoundTrip function we can see that queries that generate a large number of backend requests are negatively impacted.
For this query we created 300k jobs, but only 3000 of them finished because the limit was satisfied. The total time was 16s but you can see that only ~2s was spent searching while ~14s was spent building the backendRequests()
Taking the same query but reducing the time range. In this case roughly the exact same number of jobs were completed successfully, but the query took significantly less time simply b/c it created fewer jobs.
Log lines locations:
STARTING REQUEST
SENDING JOBS
REQUEST SATISIFED
DONE
The most obvious fix (to me) is for backendRequests() to return a channel that the main function consumes. Then we can generate the jobs in parallel.
The text was updated successfully, but these errors were encountered: