4 ms·

what advantage does this have over using something like keep-alive? http://httpd.apache.org/docs/1.3/keepalive.html http://httpd.apache.org/docs/1.3/keepalive.h

by tjpick 17y ago

what advantage does this have over using something like keep-alive? http://httpd.apache.org/docs/1.3/keepalive.html http://httpd.apache.org/docs/1.3/keepalive.html Keep alive, to me, seems better as you don't have to modify the frontend architecture. Turn it on at the server and let the server and browser do the hard work.

zemaj 17y ago
Keep alive maintains a persistent connection, you are still limited by the number of concurrent connections to the server and the latency that each one experiences. MHXR bundles all your requests into one. This leads to savings the latency overhead on each request (& probably some server resources not having to deal with multiple connections too). I tell you what; piping binary data into objects? Genius! I had no idea that was possible.
- tjpick 17y ago
  yeah, my understanding was that the overhead of a request is significantly less than the overhead of establishing a connection. So by using keepalive/persistent connections, you get the majority of the savings. All the headers and data for each file still have to get sent over the wire in the digg solution anyway, and the concurrent connections limit is the same in both cases. But thanks for explaining, I see the latency particularly is an issue.
  - Glide 17y ago
    I found this interesting tidbit on the HAProxy page: Keep-alive was invented to reduce CPU usage on servers when CPUs were 100 times slower. But what is not said is that persistent connections consume a lot of memory while not being usable by anybody except the client who openned them. Today in 2009, CPUs are very cheap and memory is still limited to a few gigabytes by the architecture or the price. If a site needs keep-alive, there is a real problem. Highly loaded sites often disable keep-alive to support the maximum number of simultaneous clients. The real downside of not having keep-alive is a slightly increased latency to fetch objects. Browsers double the number of concurrent connections on non-keepalive sites to compensate for this. Don't know if it's true or not, but it doesn't take much thought to realize if someone wanted to DDOS a server they would use persistent connections.
timdorr 17y ago
Even better: HTTP pipelining - http://en.wikipedia.org/wiki/HTTP_pipelining http://en.wikipedia.org/wiki/HTTP_pipelining Of course, that's controlled client-side and often doesn't request all that many resources at once. This is a server-side pipelining that lets them determine their own capacity (which makes sense). Of course, I'm not really sure how they're going to do this in IE, since it doesn't support decoding base64 content to image data on the page. Something tells me this is going to hit a bit of a brick wall.
- zemaj 17y ago
  Pipelining does not work in most browsers (& is disabled in FF by default). When it does work it can be flaky. A JS solution works on current technologies.

by tjpick 17y ago

zemaj 17y ago

Keep alive maintains a persistent connection, you are still limited by the number of concurrent connections to the server and the latency that each one experiences. MHXR bundles all your requests into one. This leads to savings the latency overhead on each request (& probably some server resources not having to deal with multiple connections too). I tell you what; piping binary data into objects? Genius! I had no idea that was possible.

tjpick 17y ago
yeah, my understanding was that the overhead of a request is significantly less than the overhead of establishing a connection. So by using keepalive/persistent connections, you get the majority of the savings. All the headers and data for each file still have to get sent over the wire in the digg solution anyway, and the concurrent connections limit is the same in both cases. But thanks for explaining, I see the latency particularly is an issue.
- Glide 17y ago
  I found this interesting tidbit on the HAProxy page: Keep-alive was invented to reduce CPU usage on servers when CPUs were 100 times slower. But what is not said is that persistent connections consume a lot of memory while not being usable by anybody except the client who openned them. Today in 2009, CPUs are very cheap and memory is still limited to a few gigabytes by the architecture or the price. If a site needs keep-alive, there is a real problem. Highly loaded sites often disable keep-alive to support the maximum number of simultaneous clients. The real downside of not having keep-alive is a slightly increased latency to fetch objects. Browsers double the number of concurrent connections on non-keepalive sites to compensate for this. Don't know if it's true or not, but it doesn't take much thought to realize if someone wanted to DDOS a server they would use persistent connections.

timdorr 17y ago

Even better: HTTP pipelining - http://en.wikipedia.org/wiki/HTTP_pipelining http://en.wikipedia.org/wiki/HTTP_pipelining Of course, that's controlled client-side and often doesn't request all that many resources at once. This is a server-side pipelining that lets them determine their own capacity (which makes sense). Of course, I'm not really sure how they're going to do this in IE, since it doesn't support decoding base64 content to image data on the page. Something tells me this is going to hit a bit of a brick wall.

zemaj 17y ago
Pipelining does not work in most browsers (& is disabled in FF by default). When it does work it can be flaky. A JS solution works on current technologies.