Envoy adaptive concurrency filter: sizing limits when enforcement is per worker

The Envoy adaptive concurrency filter enforces limits per worker thread; each worker independently applies the gradient controller's computed cap. With N workers, effective global concurrency approximates N times the per-worker setting. Assumption: the deployment uses N identical workers and the filter is enabled on each.

If the goal is to cap total inbound requests across all workers, set the per-worker limit to global_target / N. Caveat: circuit breaker thresholds (max_connections, max_pending_requests, max_requests) are also per-worker; dividing a global target by N may still exceed an individual worker's cap.

Latency samples that include upstream queueing may cause the gradient controller to lower the limit prematurely, since it cannot distinguish Envoy's own queueing from upstream delays. Trust the adaptive limit only when upstream latency is separately characterized or the service knee is defined by Envoy-internal queuing.

1. Run envoy -v or query the /stats endpoint to list adaptive_concurrency stats and verify per-worker naming.
2. Inspect runtime configuration for adaptive_concurrency.per_worker_limit or the equivalent field in your Envoy release; compare values across workers.
3. Observe http.adaptive_concurrency.current_limit values per worker node via /stats.

Uncertainty: field names and default values for adaptive concurrency change between Envoy releases; the config and stat names referenced here are common patterns and must be confirmed against the installed version's documentation.

To confirm the per-worker enforcement pattern in your deployment, it helps to know the Envoy version and whether http.adaptive_concurrency.current_limit values differ across workers.