4 ms·

The section on non-blocking servers is just plain wrong. .NET and IIS have had this feature for at least ~8 years now. ASP.NET Webforms and ASP.NET MVC both hav

by jconley 16y ago

The section on non-blocking servers is just plain wrong. .NET and IIS have had this feature for at least ~8 years now. ASP.NET Webforms and ASP.NET MVC both have great support for various asynchronous patterns to support non-blocking operations. ADO.NET also has this built-in. I've been involved with projects that have used these features to great effect scaling into tens of thousands of simultaneous connections per server.

mythz 16y ago
The IHttpAsyncHandler doesn't work the same as the non-blocking event loops in Unix which only uses a single process for all requests. We actually didn't fare to well ourselves and had a poor experience trying to debug them in IIS, in the end we moved to a bespoke windows service to service our comet requests. But you're right it should be included - care to contribute a piece on the topic?
- jconley 16y ago
  True, you won't get a single thread. You'll get a Threadpool. But we did like the flexibility of the Threadpool for things that had to be done synchronously or were not worth optimizing. It also allowed apps to take advantage of all CPU cores without extra configuration. With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).
  - cipherzero 16y ago
    > With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want). I am curious about this, can you provide a link or reference with more information?
    - jconley 16y ago
      http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thr... "... If you’re curious to see how much faster ASP.NET requests execute without the thread switch, you can set the value to 0. This will cause the request to execute on the IIS I/O thread, without switching to a CLR Threadpool thread. ..." Of course you would only ever set this if you are really doing every bit of I/O asynchronously in your application. Otherwise bad, bad things would happen (deadlock under load).

by jconley 16y ago

mythz 16y ago

The IHttpAsyncHandler doesn't work the same as the non-blocking event loops in Unix which only uses a single process for all requests. We actually didn't fare to well ourselves and had a poor experience trying to debug them in IIS, in the end we moved to a bespoke windows service to service our comet requests. But you're right it should be included - care to contribute a piece on the topic?

jconley 16y ago
True, you won't get a single thread. You'll get a Threadpool. But we did like the flexibility of the Threadpool for things that had to be done synchronously or were not worth optimizing. It also allowed apps to take advantage of all CPU cores without extra configuration. With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).
- cipherzero 16y ago
  > With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want). I am curious about this, can you provide a link or reference with more information?
  - jconley 16y ago
    http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thr... "... If you’re curious to see how much faster ASP.NET requests execute without the thread switch, you can set the value to 0. This will cause the request to execute on the IIS I/O thread, without switching to a CLR Threadpool thread. ..." Of course you would only ever set this if you are really doing every bit of I/O asynchronously in your application. Otherwise bad, bad things would happen (deadlock under load).