Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a service where servers upload 20kb xml files to my server.

There is no session, it is a single POST request and that's it. Each individual request is authenticated based on the contents of the xml file.

There are socket related tweaks that I will have to make as during load testing the server exhausts its sockets pool (32K).

Anyhow, I was wondering what things might change when I bring a load balancer into the equation that would round robin requests between 2+ web servers.

Could the load balancer re-use sockets?

Again, just want to be clear, client servers are posting a file over to my server, once the file has been http posted they are 100% completed. Any subsequent http posts will be considered a new 'transaction'.

share|improve this question
Wouldn't you still have an issue with the back-end server running out of sockets, regardless of how the load balancer handles it? The way I see it you'll have 2+ times the number of available sockets but the number is still finite. From where I'm sitting it looks like you need to solve this on the back-end server(s). – John Gardeniers May 11 '12 at 0:57

I'm assuming you are refering to SO_REUSEADDR rather than connection multiplexing. The only benefit this gives is that a socket in TIME_WAIT does not prevent a new socket binding to the same address. I've never come across a system which actually uses the TIME_WAIT phase for what it is intended for - if you've got lots of sockets in TIME_WAIT maybe you should just reduce the timeout.

Making it all go faster would help too - but you've not given a lot of information on the set up here and the pattern of traffic.

Any type of proxy load balancer will give you even fewer clien connections than you have now (since each incoming connection requires a connection to the back end devices). OTOH RRDNS will halve the load without the complexity and cost of a SPOF.

it is a single POST request

So we talking HTTP here? If so then then there's ENORMOUS scope for tuning.

share|improve this answer

All leading load-balancers have a form of connection reuse and pooling, they just call it something different. They are ultimately designed to process packets very quickly and efficiently.

F5 calls it OneConnect, Netscaler TCP multiplexing…..I don't know enough about the other vendors or open-source solutions.

This feature enables load-balancers to re-use TCP connections on the server-side and greatly improves the performance of the web application on the back-end. When a connection is finished so-to-speak, its moved into a reuse pool on the load-balancer and matched to a subsequent connection if suitable (if it's not suitable the load-balancer will open a new TCP connection to the server). There's no connection teardown and so there's no need for the subsequent three-way handshakes on new connections or for the server to assign or remove the memory assigned to the open sockets. The other thing to note is that the server-side connections are sequential, it's not pipelining.

Without connection re-use, it's a 1-1 correlation (between client and server) and in my experience, performance (of the application) is drastically reduced with load on the back-end server much higher. If it's SSL traffic, you'll see a CPU hit due to the key exchanges.

share|improve this answer

I think it'll depend on the load balancer. I know F5 has a feature called OneConnect that allows the load balancer to multiplex multiple requests to open sockets. This reduces the overhead of socket creation/teardown for each higher-level protocol transaction.

I know other load balancers have similar features, though I'm not as familiar with them.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.