Related to gitlab-com/runbooks!1834 (merged)
authorized_projects
is one of the highest frequency workers in the system.
Because of the rate at which these jobs are enqueued, and the bursty nature of the enqueue traffic, sidekiq dequeue rates can't keep up with our latency targets for latency_sensitive jobs (10s).
To deal with this, we can do one of two things:
- Greatly ramp up the available compute capacity to handle these jobs
- Mark these jobs as not latency sensitive and use lower thesholds
We should engage with the owning team, the Access team, on this, but I think we should consider removing the latency_sensitive_worker!
attribute for AuthorizedProjectsWorker
.
The question we need to ask is: if one of these jobs takes 60s to schedule, instead of 10s, would users consider the application performance as being degraded? Would we as the infrastructure group need to take action? cc @lmcandrew as EM for this team.
(Note that on GitLab.com presently, these jobs frequently take up to 60s, without any perceived degradation)
Queuing apdex
This shows the percentage of jobs that don't reach the current 10s threshold. Frequently only 80% of these jobs reach this threshold.
![image](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)
https://thanos-query.ops.gitlab.net/graph?g0.range_input=45d&g0.max_source_resolution=1h&g0.expr=clamp_max(%0A(%0A%20%20%20%20%20%20%20%20sum%20by%20(environment%2C%20stage%2C%20queue)%20(%0A%20%20%20%20%20%20%20%20%20%20rate(sidekiq_jobs_queue_duration_seconds_bucket%7Bqueue%3D%22authorized_projects%22%2C%20le%3D%2210%22%7D%5B1h%5D)%0A%20%20%20%20%20%20%20%20)%0A%20%20%20%20%20%20)%0A%20%20%20%20%20%20%2F%0A%20%20%20%20%20%20(%0A%20%20%20%20%20%20%20%20sum%20by%20(environment%2C%20stage%2C%20queue)%20(%0A%20%20%20%20%20%20%20%20%20%20rate(sidekiq_jobs_queue_duration_seconds_bucket%7Bqueue%3D%22authorized_projects%22%2C%20le%3D%22%2BInf%22%7D%5B1h%5D)%0A%20%20%20%20%20%20%20%20)%20%3E%200%0A%20%20%20%20%20%20)%0A%2C%201)&g0.tab=0
## Proposed apdex
On a 60s threshold, we meet the goal most of the time:
![image](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)
https://thanos-query.ops.gitlab.net/graph?g0.range_input=45d&g0.max_source_resolution=1h&g0.expr=clamp_max(%0A(%0A%20%20%20%20%20%20%20%20sum%20by%20(environment%2C%20stage%2C%20queue)%20(%0A%20%20%20%20%20%20%20%20%20%20rate(sidekiq_jobs_queue_duration_seconds_bucket%7Bqueue%3D%22authorized_projects%22%2C%20le%3D%2260%22%7D%5B1h%5D)%0A%20%20%20%20%20%20%20%20)%0A%20%20%20%20%20%20)%0A%20%20%20%20%20%20%2F%0A%20%20%20%20%20%20(%0A%20%20%20%20%20%20%20%20sum%20by%20(environment%2C%20stage%2C%20queue)%20(%0A%20%20%20%20%20%20%20%20%20%20rate(sidekiq_jobs_queue_duration_seconds_bucket%7Bqueue%3D%22authorized_projects%22%2C%20le%3D%22%2BInf%22%7D%5B1h%5D)%0A%20%20%20%20%20%20%20%20)%20%3E%200%0A%20%20%20%20%20%20)%0A%2C%201)&g0.tab=0