These days I am working on a websockets-solution based on node.js and Socket.IO. With my development server running in Azure on IIS behind the brilliant iisnode I had everything set up and ready for performing some basic load tests, or so I thought.
Reality is that you need to tweak a couple of configuration settings before IIS will let you bombard your application with thousands of concurrent long running websocket connections. It kinda makes sense!
By scouring the web for useful information about scaling concurrent connections on IIS I was soon able to get things working as expected. But since I didn’t find a complete walkthrough for my exact use case I decided to put together one myself, hoping it will make life just a little bit easier for the next person solving the same problem.
These are the settings I had to tweak to get IIS and iisnode to serve a useful number of Socket.IO websocket connections. The same should apply for other technologies, like SignalR.
- I am using the number 100.000 for everything here, change it to something you deem reasonable.
- I have highlighted things that are added or changed.
Detailed information about applicationHost.config
<configuration> <system.applicationHost> <sites> <site name="name.of.site" id="1" serverAutoStart="true"> <limits maxConnections="100000" /> </site> </sites> </system.applicationHost> </configuration> <configuration> <system.webServer> <serverRuntime appConcurrentRequestLimit="100000" /> </system.webServer> </configuration>
Detailed information about machine.config
<configuration> <system.web> <processModel autoConfig="false" requestQueueLimit="100000" /> </system.web> </configuration>
Detailed information about Aspnet.config
<configuration> <system.web> <applicationPool maxConcurrentRequestsPerCPU="100000" /> </system.web> </configuration>
Assuming you are using iisnode.
<configuration> <system.webServer> <iisnode nodeProcessCommandLine="%programfiles%\nodejs\node.exe" maxConcurrentRequestsPerProcess="100000" loggingEnabled="true" /> </system.webServer> </configuration>
Some configurations are hierarchical and the changes could probably be moved around. This works for me, but might not for you. Make sure you understand what you are doing before you try altering anything important, especially in an environment that you need working.
Also, some of these settings can (and probably should.. but you are a grown-up, you make your own decisions!) be changed through the IIS management console or through other tools.
Oh, and I am not responsible if something gets messed up.