Tedd Hansen
Tedd Hansen

Reputation: 12314

How to handle up to 100k HTTP connections in .Net

I am creating a server to monitor the online presence of clients on a webpage.

Clients will contact a (separate) server using JavaScript (on the HTML-page) to tell the server that they are alive/online.

I’m considering one of two approaches:

  1. Persistent connections with keep-alive sent regularly. This will give me much higher precision on when clients disconnect and I don’t need to update memory structure (onlineinfo) too often because we know when client comes and goes. Additional benefits to network equipment / bandwidth.

  2. Clients (re)connect at intervals to tell server they are alive. This requires a lot of connections and will necessarily decrease the accuracy. I imagine intervals like 2-3 minutes is the best we can do. 80k/120=660 connections per second… ASP.Net don’t execute too fast so I’m unsure about this. 8 core system = ~10 ms per execution.

With this many connections there are obviously some limitations. I can’t spawn that many threads simultaneously for instance. 1 request to IIS spawning an ASP.Net application will use 1 thread until request is done.

Is the best option to write a stand-alone http-server? Doesn’t .Nets TcpListener leverage httpd.sys (IIS)?

Any (constructive) thoughts on the subject would be appreciated.

Edit: Adding some useful links to this post found by following links from Nicolas Repiquets answer:

Upvotes: 8

Views: 2265

Answers (2)

Tim P.
Tim P.

Reputation: 2942

I know you specifically say .NET, but you should probably take a look at NodeJS, as it does exactly what you're trying to do, but it is server-side JavaScript.

Upvotes: 0

Nicolas Repiquet
Nicolas Repiquet

Reputation: 9265

100 000 persistent connections is not a viable option.

Sending HTTP requests at interval is way more feasible, and writing a dedicated HTTP server is an interesting choice IMO.

Take a look at this question for some orientations.

Upvotes: 4

Related Questions