Aglet

Prioritize concurrency thrashing by resource and queue risk

High concurrency deserves priority when it makes both active work and waiting work worse or pushes a shared resource toward failure. A small throughput tradeoff may be acceptable if queue age remains bounded. Weigh the resource at risk and the work displaced, then choose a setting experiment that can prove a safer ceiling.

Decide where the work belongs

  1. Rank the observable loss

    For each concurrency level, compare completed items, execution time, claim age, retries, and terminal errors. Put lost correctness or repeated work ahead of a modest slowdown. Keep a resource warning separate when useful throughput has not yet fallen.

  2. Identify the shared limit

    Group evidence by CPU, memory, database connection, lock, and external dependency pressure. Note whether multiple job classes compete for the same resource. A class-specific limit should not lead to a global worker reduction without checking unaffected work.

  3. Choose the smallest experiment

    Select immediate containment, a bounded concurrency sweep, or evidence collection for one missing trace. State the lower and upper settings to compare and the outcome that changes priority. Avoid tuning from a single saturated run with no lower-concurrency control.

What to carry forward

Queue the issue with the lost work or error consequence, constrained resource, affected job class, and matched comparison. Escalate when higher concurrency increases retries or correctness risk. Otherwise schedule a bounded sweep that can establish a class-specific ceiling without hiding other queues.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow