xhr poll error in Socket.IO default xhr-polling transport under concurrent load

Goal: Identify the root cause of latency spikes that appear only when many Socket.IO clients use the default xhr‑polling transport, as indicated by recurring 'xhr poll error' messages in client logs.

Constraints: The server runs with the default 10‑second heartbeat, exponential reconnection back‑off (starting at 250 ms), a limited thread pool, the in‑memory adapter unless Redis is configured, a maxHttpBufferSize of 1 MB, and no per‑message compression enabled by default.

Uncertainty: It is unclear whether increasing maxHttpBufferSize, enabling per‑message compression, or adjusting heartbeat/timeouts will reduce the xhr poll errors, or whether the observed latency is primarily due to thread‑pool exhaustion and Redis adapter queueing under concurrent load.

Does raising maxHttpBufferSize decrease the frequency of xhr poll errors under heavy concurrent polling?

Does enabling per‑message compression mitigate latency spikes caused by large payloads?

Is the latency primarily driven by server thread‑pool saturation rather than transport‑level configuration?