Socket exception when calling Content Provider endpoint under load

Question

I am doing some performance testing of my .NET Tridion application, simulating 500 simultaneous users requesting the home-page over a 20-minute period. On a lower-spec machine, we quickly encounter the following error:

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

We are using Tridion 2013 SP1 and DD4T 2.0 on a Windows 2012 Server. After some investigation on the server using netstat, it seems that a brand new TCP connection is being opened to the content provider endpoint every time the home page is requested. Windows 2012 allows for roughly 15,000 dynamic ports, and these are rapidly used up during the course of my 500-user simulation.

Is there a way of configuring TCP connection pooling for DD4T, or is that outside our control? I believe my question is similar to Connection pooling in the CIL (except that we are using Windows rather than Linux), which suggests that there isn't.

Has anyone else encountered this error and resolved it? :)

Answer 1

We had a similar issue one of my previous implementations, we did increase the TCP MaxUserPort on Registry, but we had a testing by 200 concurrent users only.

We did use Full page output caching and DD4T caching enabled and used ActiveMQ for caching invalidation on the web app.

Refer to this article http://blog.trivident.com/tuning-dd4t-rest/ - might help you how to increase the TCP MaxUserPort.

I hope it helps.

Answer 2

After much effort (and no little Googling) it seems that, short of implementing connection pooling in DD4T, Velmurugan's answer is the only one that will work. We ended up altering the following pair of registry settings:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort

(the number of available TCP ports to open)

• default value is 16,384 (out of a theoretical maximum of 65,536)
• we set it to 49,152, which should be fine even for a multi-tenanted machine

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay

(the length of time each connection remains open for)

• default value is 240 seconds, during which the connection will not be closed even if it isn't being used
• we set it to 30 seconds, which is apparently the smallest allowable value (although I didn't actually experiment with setting it any lower)

The combination of these two meant that (a) we had far more connections available and (b) they were being recycled far more quickly, which is enough for our load tests to work. Not exactly elegant or scalable - and pretty useless if you're not an administrator of the machine - but it got us through performance testing ...