Optimization on sidekiq-cluster concurrency settings

Problem to solve

Too low actual concurrency if run a small queue group on a dedicated server for sidekiq cluster

Intended users

System adminstrators

Further details

Example use case:

A customer may need to bulk import projects via manifest file, e.g. AOSP, from time to time. To minimize the performance impact on the main GitLab application server(s) dedicated sidekiq cluster machine is setup to handle such load only with below config while the main application server(s) or other sidekiq server handle the rest.

sidekiq_cluster['max_concurrency'] = 50 # The maximum number of threads each Sidekiq process should run
sidekiq_cluster['queue_groups'] = [
"repository_update_remote_mirror,repository_import", # whichever queues you need to process here
]

As per current logic as below on https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html#limiting-concurrency it can only run 3 jobs concurrency at a time.

For each queue group, the concurrency factor will be set to min(number of queues, N). Setting the value to 0 will disable the limit.

This will significantly limit the efficiency of job processing on the sidekiq cluster server.

Proposal

N/A

Permissions and Security

N/A

Documentation

Update the existing document.

What does success look like, and how can we measure that?

GitLab admins could have more flexibility to control the concurrency of sidekiq-cluster group and whole cluster

What is the type of buyer?

Starter or above

Links / references

/cc @dblessing @smcgivern