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

Observed behavior

I have an Objective-C networking layer where NSURLSession data-task completion handlers dispatch parsing work onto a dispatch queue. Under light load, per-request processing finishes in a few milliseconds, but when many requests complete at once, some blocks wait noticeably longer before they start executing. I am trying to decide whether the queue design or the callback integration is the bottleneck.

Current design and uncertainty

Parsing blocks are submitted with dispatch_async to a single serial queue so results stay ordered. I know from the GCD documentation that serial queues execute one block at a time, and that global concurrent queues are selected by QoS class via dispatch_get_global_queue. What I am unsure about is how NSURLSession's own delegate callback queue interacts with my serial queue: whether callbacks can pile up behind each other before my parsing blocks are even submitted, and whether moving parsing to a concurrent queue would actually help if the blocks also take a shared lock when writing results.

Assume a current Xcode and recent iOS/macOS target; I can verify with Instruments and os_signpost intervals.

Questions

1. Can the NSURLSession delegate queue itself become a serialization point that delays my dispatch_async submissions under burst completions?
2. If parsing blocks contend on a shared lock, does switching to a concurrent queue provide any real latency benefit, or does the critical section dominate?
3. Is dispatch_barrier_async on a custom concurrent queue the right documented pattern here if results must occasionally be written exclusively?