Zig std.Thread.Pool server: p99 latency spikes only under concurrent requests

I'm designing a small HTTP service in Zig built on the documented blocking std.http.Server with request handling dispatched through std.Thread.Pool (using spawnWg and a std.Thread.WaitGroup). Assume a recent pre-1.0 release, since async/await was removed and explicit threads are the supported concurrency model.

The design goal is predictable tail latency: single-request latency is expected to be fine, but I want to understand which documented mechanisms most plausibly degrade p99 only when many requests arrive concurrently. Candidates I can see in std are pool worker count versus queued tasks, synchronization overhead in the thread-safe default allocator versus per-request std.heap.ArenaAllocator instances, and contention on any shared std.Thread.Mutex-guarded state.

Because Zig's std APIs shift between releases, I will pin the exact version and read the matching std.Thread.Pool source before benchmarking, and I plan to measure rather than assume.

Which of these documented factors should I vary first in a minimal benchmark to isolate the source of concurrency-only latency? Is a fixed-size pool with a bounded queue the intended pattern for request-per-task workloads? Are there known allocator-contention pitfalls in the current std that make arena-per-request the safer default?