Qt QNetworkAccessManager vs QTcpSocket: Interoperability of concurrent network requests

Answer to the Core Questions

1. Latency difference between a shared QNetworkAccessManager and per‑thread instances when >6 requests hit the same host:

• Shared manager enforces the 6‑connection limit per host. The first 6 requests finish after roughly one round‑trip time (RTT). Each additional request waits for a slot to free up, adding about one RTT per queued request. For example, with an RTT of 120 ms: 1–6 requests ≈120 ms; 7th ≈240 ms; 8th ≈360 ms; …
• Per‑thread managers (one QNAM per thread) replicate the 6‑connection limit per manager. If you run N threads, you can have up to 6×N concurrent connections. The first 6 in each thread still see ~RTT latency, but queued requests are spread across managers, so the average wait time drops to roughly one RTT instead of many. In the 10‑thread example above, requests 7–12 still finish near 120 ms, while the 13th starts to incur a second RTT.

2. Thread‑pool size impact on latency spikes:

• Qt’s internal thread pool (default 8 threads in Qt 5.x, 4 in Qt 6.x) processes queued requests. If the pool size is smaller than the number of queued requests, each request must wait for a thread to become idle, adding an extra RTT per idle cycle. Increasing the pool size to, say, 12 threads reduces the maximum latency spike proportionally, because more queued requests can be handled in parallel.
• In practice, a pool size of max(6×N, 8) (where N is the number of per‑thread managers you plan to use) tends to keep spikes below 1–2 RTT.

3. Dedicated QTcpSocket pool in separate threads:

• By creating a raw QTcpSocket for each worker thread, you bypass the 6‑connection limit entirely. Each socket can be used immediately, so latency is essentially the raw RTT plus any TLS or server processing overhead—no queuing.
• Trade‑offs: each thread consumes an event loop, increasing context‑switch overhead and memory usage. Manual connection management (reconnect, error handling, cleanup) is required, whereas QNAM handles these automatically.
• For workloads with dozens or hundreds of concurrent requests, the per‑thread QNAM approach is usually simpler and less error‑prone; the raw socket pool shines when you need the absolute lowest latency and can tolerate the added complexity.

Assumptions & Verification Guidance

• Qt version 5.15 or 6.x (connection‑limit and thread‑pool defaults are documented for these releases).
• Network conditions: RTT is constant and TLS handshake time is negligible compared to round‑trip latency.
• Requests are simple HTTP GETs to the same host.

To validate these numbers in your environment:

1. Create a benchmark that launches 10 GET requests to the target host using:
   • Case A: one shared QNetworkAccessManager.
   • Case B: 10 separate managers (one per thread).
   • Case C: a pool of 10 QTcpSocket objects, each running in its own worker thread.
2. Record start and finish timestamps per request (e.g., using QElapsedTimer).
3. Compute average, median, and maximum latency for each case.
4. Adjust QNetworkAccessManager::setThreadPoolSize() (if available) to 4, 8, 12, etc., and observe how the maximum latency changes.
5. Profile the QTcpSocket pool with a tool such as perf or QtCreator Profiler to count context switches and CPU usage.

What We Still Need to Know

To fine‑tune the recommendation for your specific workload, could you provide an estimate of the round‑trip time to the target host? Knowing the RTT lets us translate the “one RTT per queued request” rule into concrete milliseconds for your scenario.