Performance

A TCP cumulative acknowledgment identifies the next byte expected in order. If a segment is missing but later bytes arrive, that acknowledgment cannot advance across the hole. Selective Acknowledgment, or SACK, adds information about received byte ranges beyond the cumulative boundary. It helps a sender distinguish missing data from data already queued at the receiver, improving the information available to its recovery algorithm. ...

Saving a round trip depends on the protocol and early-data mode. In TLS 1.3, an ordinary full handshake and a resumed handshake without early data normally both take one TLS round trip. Resumption can still reduce certificate transmission and authentication work. Enabling tickets does not make every HTTPS request start one RTT sooner. ...

HTTPS latency combines several stages, and a warm request may avoid some without making cryptography faster. DNS, connection acquisition, TCP setup, TLS authentication, server work, and response transfer have different clocks. First determine which stages actually ran. Request duration alone cannot distinguish an existing connection from a new connection that resumed a TLS session. ...

HTTP persistence lets several request and response exchanges use one connection. That can avoid repeated TCP setup and, for HTTPS, repeated TLS negotiation. The benefit depends on latency, request size, and whether another usable connection already exists. Persistence does not make application work disappear, nor does it promise that a socket will remain open indefinitely. ...

EXPLAIN shows the execution plan selected for a statement. It helps locate expensive work and mistaken estimates, but a slow request can also involve locks, network transfer, or application behavior outside the plan. Use plan evidence to test a specific hypothesis rather than assuming that every performance problem requires a different scan or another index. ...

Load shedding deliberately refuses some work when accepting everything would threaten useful service. The aim is to preserve capacity for work that can still complete, not to promise that every accepted request will be fast or important. Rejection is itself work, so the admission point and its cost matter as much as the threshold. ...

A materialized view stores the result of a defining query so later reads can access those stored rows. It moves computation from every read into refresh operations, which can benefit repeated reporting queries. The tradeoff is an explicit freshness boundary and another relation to maintain; neither instant reads nor automatic synchronization with the source tables is guaranteed. ...

A request-body limit bounds accepted input, not merely the number written in Content-Length. Enforce it while consuming the body, before committing application effects. Compressed input needs separate limits for encoded and decoded bytes. A 413 response is useful only if the expensive allocation or irreversible write has not already happened. ...