NSURLSession callbacks and GCD serial queue: latency spikes only under concurrent requests

Direct Answers

1. Yes, the NSURLSession delegate queue is a serialization point; callbacks execute there before your dispatch_async submits parsing blocks, so under burst completions they pile up first.
2. Switching to a concurrent parsing queue only reduces latency if the shared lock protects a short critical section; if the lock covers the full parse‑and‑write, contention moves from queue wait to lock wait and concurrency helps little.
3. Use dispatch_barrier_async on a queue created with DISPATCH_QUEUE_CONCURRENT for exclusive writes; on a serial queue it behaves like dispatch_async and provides no exclusion.

Confirmed Facts

• NSURLSession invokes delegate callbacks on the queue passed to initWithConfiguration:delegate:delegateQueue: (or a private system queue if nil).
• A serial delegate queue guarantees callback order but creates head‑of‑line blocking.
• Your parsing serial queue adds a second FIFO; GCD does not coalesce across the two queues.

Likely Explanation

The observed latency spikes are the sum of wait time on the delegate queue plus wait time on your parsing serial queue. If the delegate queue runs at a lower QoS than your parsing queue, priority inversion can add further delay. When the shared lock spans the entire parse‑and‑write operation, the parsing queue behaves effectively serial regardless of its concurrency attribute, so moving to a concurrent queue yields little benefit.

Verification Steps (Run Once, Decide)

1. Add os_signpost intervals around: (a) delegate callback entry, (b) dispatch_async call, (c) parsing block start, (d) lock acquire, (e) lock release.
2. Profile with Instruments Time Profiler + "Record Waiting Threads" under a reproducible burst (e.g., 50 concurrent requests). Plot the intervals to see where the 99th‑percentile time accumulates.
3. Repeat with three delegate‑queue configurations: (1) your current serial queue, (2) a concurrent delegate queue with manual ordering, (3) nil (system queue). Compare tail latency.
4. Measure lock hold time (signpost d–e). If median > 1 ms, a concurrent parsing queue will not help; reduce the critical section instead.

One Missing Diagnostic Detail

What is the typical lock hold time (parse + write) for a single response? If it stays under ~200 µs, a concurrent parsing queue with dispatch_barrier_async for writes will likely cut tail latency. If it is in the millisecond range, the lock is the bottleneck and queue topology changes won’t matter—focus on making parsing lock‑free or sharding the result store.