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

Short answer

No — raising maxHttpBufferSize will not meaningfully reduce xhr poll error frequency under heavy concurrent polling, and enabling per-message compression is more likely to make things worse than better. The evidence points to server-side resource saturation (thread pool / event-loop pressure from thousands of short-lived HTTP requests) as the primary driver, not transport-level configuration.

Why maxHttpBufferSize is the wrong lever

maxHttpBufferSize (default 1 MB) only matters when a single message or polling response actually approaches that limit. An xhr poll error is a client-side signal that a polling request failed — typically due to a timeout, a dropped connection, or a 5xx response from the server or proxy — not because a payload was rejected for size. Unless your logs show payloads near 1 MB, raising the limit changes nothing about failure rates. It only raises the ceiling for memory a single oversized request can consume, which is mildly risky under load.

Compression: a trade, not a fix

Per-message compression shrinks payloads on the wire, which can help if your latency spikes correlate with large messages on constrained bandwidth. But compression costs CPU on every message for every client. With xhr-polling, that CPU cost is paid on every poll cycle, not just when data flows. Under concurrent load — where your suspected bottleneck is already CPU/thread-pool saturation — enabling compression can amplify the very exhaustion causing the errors. Treat it as a targeted optimization for large-payload workloads, verified by measurement, not a general remedy.

The likely root cause: polling economics

XHR polling is structurally expensive. Each client issues a full HTTP request/response cycle for every poll, and with many clients the request rate multiplies fast. Consequences that match your symptoms:

• Thread-pool / event-loop saturation: each poll occupies a worker while it waits or processes. When the pool is exhausted, new polls queue, exceed timeouts, and surface as xhr poll error on the client.
• Heartbeat interplay: with a 10-second heartbeat, a server that is briefly saturated can miss the window, and clients then enter exponential back-off (starting at 250 ms), producing reconnect storms that add more load — a feedback loop.
• Redis adapter queueing: if Redis is configured, every broadcast adds network round-trip and serialization latency to the poll response path. The in-memory adapter avoids this but does not scale across nodes. Either way, adapter latency shows up as slower poll responses, which compounds pool occupancy.

What to verify before changing anything

1. Correlate errors with server state. Capture CPU, event-loop lag (Node.js: perf_hooks.monitorEventLoopDelay(), or clinic doctor) or thread-pool utilization during a spike. If errors align with saturation, transport tuning is confirmed as secondary.
2. Inspect the failing responses. In Chrome DevTools or a proxy log, check whether failed polls return 503/504, time out, or are reset. Timeouts and 5xx point at server/proxy capacity; connection resets may point at a proxy or keep-alive misconfiguration in front of the server.
3. Compare adapters. Run the same load against the in-memory adapter and the Redis adapter. A marked difference implicates Redis queueing; no difference implicates the polling loop itself.

Changes that actually help

• Prefer WebSocket upgrade. The single most effective fix is ensuring clients can upgrade off polling (check that proxies allow Upgrade headers). WebSockets eliminate the per-poll HTTP cycle entirely.
• Lengthen polling intervals / heartbeats cautiously. This reduces request frequency but delays dead-connection detection — a deliberate trade-off.
• Scale the bottleneck. Increase pool capacity or add nodes behind a sticky-session load balancer, since xhr-polling requires session affinity.

Uncertainty

One detail would sharpen this recommendation: the HTTP status (or absence of one) on the failed poll requests. If failures are clean 4xx responses rather than timeouts, the diagnosis above would need revisiting toward payload or framing issues.