4 ms·

My current favorite is chunked encoding. Does amazon.com really make it's page more performant by sending 25 chunks less than 2k, some less than 50 bytes, whil

My current favorite is chunked encoding. Does amazon.com really make it's page more performant by sending 25 chunks less than 2k, some less than 50 bytes, while I'm trying to grab 115k for a page? It's all so weird to me.

marcosdumay 6y ago
It may make a huge difference for their servers, that can generate 2kB of data and send you right away, instead of generating the entire 115kB before they can send it. Those 2kB is a bit too small for top network performance, so you may see a negative impact. But if they increase it to something like 10kB, it's harmless.
- banana_giraffe 6y ago
  I can get it sometimes, but some sites are just bizarre. twitter.com sends out a few dozen 74 byte chunks. I can't find it now, but I've seen pages composed of chunks of 10 or 20 bytes big. So much overhead.
  - marcosdumay 6y ago
    Some frameworks make it really easy to create reusable code that calculates something, pushes it into the network, and returns to the rest of the page. You are right that it's not a great thing to do. A little bit of buffering on the sender can improve things a lot. But it's an easy thing to do, so people do it.
zlynx 6y ago
From my experience (not with amazon) these strange chunk sizes come from non-blocking IO. When a source gets some data and triggers select/poll/epoll/whatever, the callback (or equivalent) immediately writes it out as a chunk. This works even better in HTTP/2 or HTTP/3 / QUIC. A Go server reading from a lot of microservices can produce pretty weird output on HTTP/2 because now not only is it in odd sizes determined by network timing, it doesn't even need to be in order.
halter73 6y ago
Usually it's because the app doesn't know the length of the entire response body up front and wants to start sending the response before buffering the whole thing. The 50 byte chunks probably aren't that useful, but that can happen as a consequence. Something like nagling can prevent those small chunks, but then there would likely be higher latency.

marcosdumay 6y ago

It may make a huge difference for their servers, that can generate 2kB of data and send you right away, instead of generating the entire 115kB before they can send it. Those 2kB is a bit too small for top network performance, so you may see a negative impact. But if they increase it to something like 10kB, it's harmless.

banana_giraffe 6y ago
I can get it sometimes, but some sites are just bizarre. twitter.com sends out a few dozen 74 byte chunks. I can't find it now, but I've seen pages composed of chunks of 10 or 20 bytes big. So much overhead.
- marcosdumay 6y ago
  Some frameworks make it really easy to create reusable code that calculates something, pushes it into the network, and returns to the rest of the page. You are right that it's not a great thing to do. A little bit of buffering on the sender can improve things a lot. But it's an easy thing to do, so people do it.

zlynx 6y ago

From my experience (not with amazon) these strange chunk sizes come from non-blocking IO. When a source gets some data and triggers select/poll/epoll/whatever, the callback (or equivalent) immediately writes it out as a chunk. This works even better in HTTP/2 or HTTP/3 / QUIC. A Go server reading from a lot of microservices can produce pretty weird output on HTTP/2 because now not only is it in odd sizes determined by network timing, it doesn't even need to be in order.

halter73 6y ago

Usually it's because the app doesn't know the length of the entire response body up front and wants to start sending the response before buffering the whole thing. The 50 byte chunks probably aren't that useful, but that can happen as a consequence. Something like nagling can prevent those small chunks, but then there would likely be higher latency.