Performance New Added 26 September 2026

Requests take a multiple of 40ms more than the work needs

Nagle's algorithm holds a small write until the previous segment is acknowledged, and the peer's delayed ACK holds that acknowledgement for up to 40ms hoping to piggyback it on data. Neither side is overloaded, they are waiting for each other, which is why the extra time is suspiciously constant and only affects requests split across two writes.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

# The tell is a flat 40ms (200ms on some stacks) added to small requests
tcpdump -i any -nn 'tcp port 8080' -ttt | head -40

# Fix the write pattern, not the network: one write per message
# Python
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
# Java
socket.setTcpNoDelay(true);
# Node.js
socket.setNoDelay(true);
# Go sets it for net.Conn already, so check the bufio.Writer you wrapped it in

# Proxies usually set it, confirm rather than assume
grep -R tcp_nodelay /etc/nginx/

# Writing headers and body separately is the classic trigger, so buffer
# them and flush once instead of leaving the kernel to decide

# Sanity check with a client that writes in one go
curl -s -o /dev/null -w '%{time_total}\n' -d @body.json localhost:8080/api

How to diagnose Performance errors

Performance failures rarely produce an error message. They produce timeouts elsewhere. The three classic causes are stop-the-world garbage collection, thread pool starvation (all workers blocked on I/O so new requests queue), and event loop blocking in single-threaded runtimes. All three look identical from outside: latency climbs, then upstream timeouts fire. Distinguishing them requires looking inside the process.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Measure the p99, not the mean. Averages hide exactly the pauses that cause timeouts.
For the JVM, enable GC logging (-Xlog:gc*) and correlate pause durations with latency spikes before tuning anything.
For thread pools, log active versus queued task counts. A queue that grows while CPU is idle is starvation, and the fix is asynchronous I/O, not more threads.
In Node.js, measure event loop lag directly (perf_hooks.monitorEventLoopDelay). Any synchronous work over a few milliseconds per request will show up here.
Profile before optimising. pprof, async-profiler, py-spy and Chrome's profiler all point at the real hot path, which is rarely where intuition suggests.

Tools worth reaching for

async-profiler
go tool pprof
py-spy
perf_hooks.monitorEventLoopDelay
-Xlog:gc*

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

man7.org datatracker.ietf.org

Related Performance errors

See all 19 Performance errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.