Compression trade-off
Compression trades CPU time for fewer bytes on the wire. 1,000 responses/s of 200 KB need 1.6 Gbps, more than a 1 Gbps link carries. A middle compression level fits the link and leaves CPU free.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | No compression | Compression level 4 |
|---|---|---|---|
| p99 latency | under 180 ms | 10.1 s Fail | 77 ms Pass |
| CPU use | under 75% | 0.6% Pass | 50.9% Pass |
| Error rate | under 0.1% | 31.8% Fail | 0% Pass |
| Monthly cost | 128 USD/mo | 128 USD/mo |
Key numbers
| Number | Value |
|---|---|
| Default network link of a server | 1,000 Mbps |
| CPU time for one API call | 0.3 ms |
| Payload factor with no compression | 1 ratio |
100 images/s · 1,600 of 1,000 Mbps · it does not fit
How it works
A link carries a fixed number of bits each second. Multiply the response size by the response rate, and by 8 bits for each byte. In the mini board 1,000 responses/s of 200 KB make 1,600 Mbps. The server has a 1,000 Mbps link, so the link is full and p99 passes the limit.
Compression makes each response smaller before it leaves the server. Text, JSON and HTML often shrink a lot. Smaller responses fit the link, and the queue at the link goes away.
The price is CPU. Each response must be compressed, and higher levels need more time for each byte. At some point the extra CPU gives only a few percent of extra savings. The server then runs out of CPU before it runs out of link. In the mini board level 4 fits the link and keeps CPU under 75 percent. The highest level does not.
Compression helps only when the data can shrink. Images, video and encrypted data are already dense, and compression adds CPU for little gain.
In the levels you tune the level so that both the link and the CPU have room.