3 ms·
> Rolling out the above changes went relatively smoothly until one of the curious engineers on our network team found that compression was actually a bottleneck
by donatj 5y ago
> Rolling out the above changes went relatively smoothly until one of the curious engineers on our network team found that compression was actually a bottleneck on high bandwidth connections
Back in the early-to-mid-aughts there was a push to start gzip-ing server responses.
It was my general experience at the time that this actually often made the browsing experience worse. Whereas without compression the page would begin to render as the html began to trickle in (very slow internet back then), when compressed you had to wait for the entire document to download and be decomposed first.
Uncompressed you could often decide if the page was worth waiting for entirely before it finished downloading.
- gampu 5y agoNot sure how compression was a bottleneck on the high bandwidth connections? I understand @donatj's comments about having to wait for the entire file to be downloaded before rendering, but that would be a user experience issue, not sure how the network team sees it as a bottleneck on the network?
- tshaddox 5y agoI assume they meant that the network could move bytes faster than the CPU could compress them.
- kevinday 5y agoHTTP requires that the length of the content be sent before the content, so that pipelined connections know where the data ends and the next headers start. If you're sending a file directly off disk you know the size before you've even looked at the data so there's no delay. If you're running everything through gzip, you have to wait to compress the entire file before you know the output length, so the critical "time to first byte" metric could get much worse. There are similar issues with dynamic content (CGI scripts, PHP, etc) where both the server and browser would end up buffering large amounts of content before compressing/decompressing them, which also affected perceptual speed. If the connection bandwidth was high enough, skipping all of this and just sending the uncompressed file would appear faster to the user, despite transferring more. This was later improved with things like chunked encoding and caching the compressed output on the server side, but they came later and weren't always supported or desirable.
- davidmurdoch 5y agoGzip is streamable (windowed), so perhaps it was the extra CPU cycles that caused the slow down, misconfigured gzip, or just incomplete gzip implementations?