27

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?

Polymorphix
  • 1,066
  • 1
  • 12
  • 29
Kamyar Nazeri
  • 25,786
  • 15
  • 50
  • 87
  • 2
    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. –  Apr 02 '12 at 19:33
  • 1
    Have you checked out SignalR? https://github.com/SignalR/SignalR – mgnoonan Apr 02 '12 at 19:33
  • @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 Apr 02 '12 at 19:36
  • @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 Apr 02 '12 at 19:40
  • 1
    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: https://github.com/SignalR/SignalR/wiki/Performance – Paul Batum Apr 12 '12 at 03:37
  • Related: https://stackoverflow.com/questions/30500495/set-limit-concurrent-connections-for-websocket-on-iis-8 – Janez Kuhar Dec 23 '22 at 10:35

2 Answers2

40

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
Kamyar Nazeri
  • 25,786
  • 15
  • 50
  • 87
  • 1
    Do WebSocket connections (that means post-handshake) actually count as "concurrent requests" in the sense of these parameters? – John Dec 13 '13 at 13:41
  • 1
    A WebSocket (even when idle) is a persistent connection, so yes, they do count as concurrent requests – Kamyar Nazeri Dec 13 '13 at 14:25
  • Technically yes, but the semantics are different here. WebSocket connections are intended to stay open without consuming resources, whereas http requests almost always consume resources will running. That's why it doesn't make too much sense to use the same restriction parameters for both types of "requests". Since it doesn't make sense it's reasonable to suspect that there might be something to point out about it here. – John Dec 13 '13 at 14:34
  • 5
    Using HttpListener/OWIN I've managed to get 982Mbps outbound via .NET Websockets via SSL in C# on a single Azure VM - so the throughput is pretty good too. – Ben Adams Jan 11 '14 at 11:33
0

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.

moka
  • 22,846
  • 4
  • 51
  • 67
  • This pretty much explains Winsock, However, is ASP.net WebSocket implemented by Windows Socket API? – Kamyar Nazeri Apr 04 '12 at 17:27
  • WebSockets is just extra layer over TCP layer that adds some data over it that server and client has to exchange for handshake and then framing for data packages. As I know Sockets in .Net are implemented using WinSockets. In Mono probably they use another API to be working on Linux. – moka Apr 04 '12 at 17:34
  • This entire answer is wrong. The ephemeral port issue that limits some socket based systems to 65k connections does not apply to WebSockets. You can connect *easily* over 100k WebSocket connections to a single server running ASP.NET 4.5 WebSockets. – Paul Batum Apr 09 '12 at 16:37
  • 1
    Paul, please read carefully: > On single networking device you can Bind a bit less than 65k sockets. This is listening sockets that accept connections. That means you can BIND (which is so-called "server socket"). It does not applies to Client sockets. You might have as much as hardware, software and OS can handle. That what I did said. So your comment is right: you can have much more than 65k client sockets. Again: read please carefully what is written in answer. And check out what is socket binding, listening, and what is server / client sockets. Regards. – moka Apr 10 '12 at 10:41
  • 4
    Maksims, your answer is still misleading. The OP wants to understand the scalability of ASP.NET 4.5 WebSockets. The number of networking sockets that can be bound is not relevant to this question. You have taken a general purpose .NET sockets programming answer and pasted it into an ASP.NET WebSockets question. For example, you listed blocking sockets as an option, but .NET 4.5 does not even expose blocking WebSocket APIs. – Paul Batum Apr 12 '12 at 02:53
  • The answer is more related to sockets it self - yes. Because there is lots of own implementations, and that is one of the scenarios - making own WebSockets protocol. That's why I covered most of details that might apply development of such and with technology. I will edit my answer to be more related to question. – moka Apr 12 '12 at 09:16
  • @PaulBatum: What you are saying about having over 100K WebSocket connections, makes me feel a bit iffy and this is where im not sure if there is a good way to config the connections somewhere in the framework! Correct me if im wrong, WebSocket is sessionful I assume, yet the number of HTTP requests are limited to the **Queue Length** flag in the IIS application pool, I was wondering if the number of requests could exceed the *Queue Length* of the application pool? Is there any other configuration that could limit the number of concurrent requests, like maxConnections of WCF TCP binding config? – Kamyar Nazeri Apr 12 '12 at 12:58
  • 1
    WebSockets are not sessionful. If the implementation is based on ASP.Net WebSockets, then they will relay on some of IIS settings, but they are not related to HTTP requests or something similar, because they are not HTTP request, but they are pure TCP connections with extra layer on top. – moka Apr 12 '12 at 13:18
  • 2
    @KamyarNazeri Yes there are number of throttles you will need to relax. I posted a comment against the question itself linking to SignalR's guide to the various throttles that may limit how many WebSocket connections your server can accept. Here it is again: https://github.com/SignalR/SignalR/wiki/Performance – Paul Batum Apr 13 '12 at 18:43
  • 1
    Also, Maksims is incorrect about the relationship between WebSockets and HTTP. Because WebSocket connections are initiated by a HTTP handshake, some of the IIS throttles that apply to HTTP requests will also apply to WebSockets. – Paul Batum Apr 13 '12 at 18:44
  • 1
    Applying IIS rules over WebSockets traffic will be implemented only in IIS 8 and .Net 4.5. Before that, WebSockets traffic, handling handshake and messaging will be out of track from IIS side and will work directly with server socket implementation. – moka Apr 14 '12 at 17:32
  • @MaksimsMihejevs If you edit your answer and elaborate on this last comment of yours it would be strongly improved and fewer people would have the knee-jerk reaction of assuming that you don't know what you are talking about (I did too at first). – John Dec 13 '13 at 13:27
  • @John thanks for a comment, I've wrote this answer some time ago, when my english skills were a bit rough (still are :D), that might confuse a lot as well. So I've added comment at the top of answer, just to make sure that I clarify what this answer is related to and what it does not. Thanks for a comment. – moka Dec 13 '13 at 13:50