4 ms·
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
by 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 agoI 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.