Given that, there is no theoretical limit to number of concurrent TCP connections a Windows 2008 server can handle. Only thing will happen is, with each connection there will be memory consumption in server. Unfortunately, memory is not unlimited (and I want to utilize only physical memory).

For example, lets say we've 2GB server memory. Now there are two extreme cases:

  • Case 1: If we've allocated 64KB buffer for each connection (only to receive incoming request), then 32768 connections can consume all the 2GB of memory. This will not leave any memory to queue/process incoming requests from those connections.

  • Case 2: On the other hand, lets say a single (or very few) connections continuously keeps sending request buffers (for example, video streaming from one connection to other) and server cannot process them within time, those buffers will get piled up in server and eventually will occupy most of the servers memory. And it will not leave any memory for new connection thereafter.

This is the real dilemma in server design bugging me badly for last many days.

If I can decide on max size of request buffer per connection and max number of requests to allow in queue per connection. Then, based on available server memory, it will then automatically set limit on max number of concurrent connections.

How to decide on these limits to achieve best performance and throughput? I am just looking for perfect utilization of server resources.

Are there any standard guidelines or empirical data available with someone who can share with me please.


There are finite limits to the number of concurrent TCP connections a server can achieve but they are so large they don't really count. Server resources will always be constrained first.

The problem with your question is that it is largely dependant on your application, hardware, os configuration and use case. The only real way to get an idea of what your setup is capable of is to come up with a set of representative load tests and run them as you develop your service. As you note in Case 2, there are any number of variable that can blow your Case 1 calculations out. The TCP receive buffer is only one component to a connection. The OS will maintain other data and state per connection and your application will have other requirements per connection, or for a running request in addition to all that. Jeff Darcy has a good article on high performance server design from a software point of view.

So my answer is: load test, load test, load test, then load test some more.

Even then the real world tends to pop up things you had never thought of, which you add to your load profile and start the testing cycle again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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