Aglet

Investigate worker concurrency with a bounded sweep

A bounded sweep reveals the point where parallel workers stop adding useful service. Keep input and worker code stable, test a small set of levels, and align resource traces with claim and completion events. Separate a downstream bottleneck from contention introduced by worker concurrency.

Build a useful investigation brief

  1. Choose comparable concurrency levels

    Run the same sanitized workload at a conservative level, the current level, and one higher level. Record job shape, worker count, queue, database state, and start time. Repeat enough to expose a consistent boundary without changing the workload between levels.

  2. Align resources with job phases

    Place CPU, memory, connection pool, lock wait, I/O, retry, and completion events on the same timeline. Identify which phase saturates first and which jobs are delayed. If the resource trace is incomplete, leave that gap explicit rather than assigning a mechanism.

  3. Test a class-specific ceiling

    Apply one bounded concurrency ceiling to the affected job class and compare it with the current setting under the same workload. Check other queues for displaced capacity. Keep a faster completion result qualified if errors, retries, or claim age worsen.

What to carry forward

Deliver the sweep matrix, first saturation point, phase-aligned resource evidence, and class-specific ceiling result. State what the data cannot distinguish, such as database contention versus external latency. The investigation is actionable when the next setting and its observable guard are clear.

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