Limiting performance factors of WebSocket in ASP.NET 4.5?

24
votes

MSDN documentation doesn't seem to have good coverage on ASP.net 4.5 support of HTML5 WebSockets protocol!

This is what I'm looking for:

  • How many live connections can a server/application/cpu support?
  • Is there any maximum number of incoming connections that could be set/get?
  • What is the optimum number of sockets per application regardless of data transfer over the socket?

Update:

Requests from flash RTMP sockets (an alternative to websocket) could be well configured on Adobe Media Server application server. Isn't any sort of configurations for number of requests, ideal time, size of chunks, ... for ASP.net inside application or IIS 8 configuration?

2
c#asp.nethtmlwebsocket
I imagine most of these will be "soft factors" (e.g. a function of the server/network load) unless there is a "hard limit" configured somewhere. – user166390
Have you checked out SignalR? github.com/SignalR/SignalR – mgnoonan
@mgnoonan: No, I had not seen it, however it seems to be a third .net party library, what I'm looking for is the built-in support of webcocket in asp.net 4.5 and its possible limitations – Kamyar Nazeri
@pst: So theoretically it could be unlimited? That doesn't seem right, since the number of HTTP requests in an application pool are limited, I was wondering if the numbers of sockets could also be limited in an application/IIS application pool? – Kamyar Nazeri
ASP.NET has a number of inbuilt limits that you will need to relax when experimenting with WebSockets scalability. The SignalR guys have a good guide on this: github.com/SignalR/SignalR/wiki/Performance – Paul Batum

2 Answers

37
votes

To whomever may be interested:

  • Over 100k WebSocket connections can be made to a single server running ASP.NET 4.5

  • WebSocket connections are initiated by a HTTP handshake, hence some of the IIS throttles that apply to HTTP requests will also apply to WebSockets. appConcurrentRequestLimit in the IIS Configuration can be used to set the maximum concurrent requests per application:

    <serverRuntime appConcurrentRequestLimit="250000" />

  • Maximum concurrent connections to an ASP.net 4 Web Application can be set with ApplicationPool's maxConcurrentRequestsPerCPU property:

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="20000" />
</system.web>

  • When the total amount of connections exceed the maxConcurrentRequestsPerCPU setting, ASP.NET will start throttling requests using a queue. To control the size of the queue, you can tweak the machine.config requestQueueLimit:

    <processModel autoConfig="false" requestQueueLimit="250000" />

  • The following performance counters should be considered while conducting concurrency testing and adjusting the optimum settings detailed above:

    • NET CLR Memory #bytes in all Heaps
    • ASP.NET\Requests Current - Queued - Rejected
    • Processor Information\Processor Time
    • TCP/IP Connections Established
    • Web Service\Current Connections - Maximum Connections
    • .NET CLR LocksAndThreads\ # of current logical Threads - # of current physical Threads
0
votes

EDIT: This answer is related to .Net 4.0 or older versions, where WebSockets have to be implemented by your own (.Net 4.5 + IIS provides you with solution). So it only relates to your own implementation of WebSockets on top of TCP Layer.

Amount of sockets that can be handled by .Net is based on system and the way you serve the sockets. Read this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms739169%28v=vs.85%29.aspx

WebSockets implementation is using Asynchronous way of serving Receiving and Sending of data. That makes them very scalable and does not require a lot of memory per connection. So amount of connected sockets is based on complexity of your application logic to each connection and hardware. In most cases you will face performance issues with processing application logic, then facing performance issues that will be based just on connected sockets.

If you are using own implementation that is based on raw TCP Sockets then this information will apply:

On single networking device you can Bind a bit less than 65k sockets. This is listening sockets that accept connections. In usual server implementations you would almost never use more then a few or maybe few 10ths of sockets for accepting connections.

Client sockets can be as many as your implementation and memory can handle.

There is many ways of serving sockets, that allows you to handle more sockets. Few highlights:

  1. Blocking way of serving sockets will delay of serving each socket. As well non-blocking read of client sockets will use your cpu for just checking if there is any data available. With huge amount of sockets it can be very costy.

  2. Thread per client socket will use huge amount of memory (more then 1mb per thread), that will allow you small amount of sockets per physical system.

  3. One of the best (imho) options is using Asynchronous socket. That allows you to have thousands of sockets, and with good implementation more that tens or even hundreds thousands sockets on single server system.