Comet Programming in IIS

Question

It is said that IIS is not recommended for Comet programming. If that is true, how is it that other web servers are able to handle this vis a vis IIS. So what is it that other web servers do additionally which allows them to scale out.

Enthusiasm

It was.. You may need a good Comet Ajax implementation : pokein.codeplex.com and IIS Tuning tool : iistuner.codeplex.com – Delorasdelorenzo

Answer 1

For some reason, this myth is still around. It's certainly possibly to do this with IIS, as demonstrated in our IIS-based comet server, WebSync.

The myth started with standard ASPX pages (which, if you hold open, will crap out around maybe 100 or so requests tops). It got better with async pages and handlers (which idle using much lower memory and virtually no CPU), and, with some clever working, can scale as well as, if not better than, many other comet solutions.

Cecilla

Aside from the framework and functionality that makes it easier to program Comet with ASP.NET/IIS using WebSync, how is WebSync so much faster than straight Comet programming against IIS with a custom http handler or *.ashx or web service? I just checked it out as we use Comet a lot but I didn't see any technical details on the site of how WebSync achieves the performance you claim (I'm not disputing, just looking for more informatino). – Philis

@Sam: for the performance, we've got custom threading/threadpool management that's designed to scale in IIS without starving the threadpool, massive optimizations to the serialization/deserialization of the messages to minimize request processing and memory, a whole pickup/distribution methodology to handle distributed loads and server clusters, etc. Lots of things go into making it hit those numbers :) – Cecilla

when a request comes into IIS on a worker thread, how do you take over that request on a separate thread and later send back a response but still return the original worker thread back to ASP.NET? That's the part that has me curious. – Philis

@Sam: the async handlers from .NET automatically drop back into the wait pool once you've handled the beginprocessrequest, but the request is completely idle until you complete it, so as long as you properly track your resources, you just let the request sit around, using virtually no resources, until you need it again. See msdn.microsoft.com/en-us/magazine/cc164128.aspx#S4 – Cecilla

Answer 2

I'd also suggest checking out aspcomet.googlecode.com - open source and runs in IIS.

Hatchment

Answer 3

A Comet connection means an HTTP connection between the server and the client (the Web page itself) which is left open for a longer time period. The server needs to have the following capabilities set up correctly:

1. Multiple parallel connections to the same browser (the maximum number of connections per client has to be set to at least 2)
2. The connection timeout (inactivity) has to be set high enough and the Web page must be capable of re-initiating lost Comet connections.
3. The server has to be able to run server-side scripts for an extended time period, so the "processing timeout" has to be set high enough, e.g. 1800 seconds or so.
4. It is useful to support HTTP 1.1, but not required for Comet.

The easiest way is to use a JavaScript framework with built-in support for Comet. See the framework's manual for more instructions on how to configure various Web servers (like IIS) correctly for Comet.

Tetralogy

Answer 4

We have moved away from using IIS to using a custom web server built using HttpListener. IIS imposes resource limits and screws up debugging any other ASP.NET web application you have. Running it on a different App Domain minimizes but does not resolve the problem.

Slatternly