问题在于传统的web服务器使用每个套接字一个线程的方法来处理并发用户，这对于comet / long polling技术并不总是最优的。（然而，较新版本的IIS有一种方法可以插入自己的连接处理程序，我将在下面介绍。）
对于传统的web服务器，更多的目标是建立连接，尽快为用户提供服务，并转移到下一个连接。如果连接持续了很长时间，那么它可能正在执行一些密集的操作，例如大型下载或巨大查询，但总体上它正在使用CPU，因此线程模型非常有效。
在comet（长轮询）中，通常您连接到一个Web服务器，在那里您只需等待事件发生，往往会促进更多的并发连接。同时，许多这些用户都在等待跨全局发生相同的事件。
分配一个线程，然后让用户主要旋转和等待并不是这种类型的最佳模型。更好的模型是基于事件循环的 Web 服务器，以异步方式执行所有操作，并且将事件分派给多个用户时不涉及每个客户端的昂贵上下文切换。Node.js 就是基于这种模型构建的（使用 libevent 作为其核心），同时还有 Ruby Eventmachine、Twisted Python、Friendfeed 的 Tornado、Jetty 和基于 C# 的 Manos 服务器。
这就是为什么通常更有优势将 Comet 放在自己的进程中，使用自定义服务器，因为传统的 Web 服务器如 Apache 和较旧版本的 IIS 并不以对 Comet 的需求高效的方式运行。
标准的ASP.NET应用程序有点麻烦，因为.NET中的线程池仅限于25个通用线程和25个IO线程（而http连接需要一个IO线程）。实际上，您可能会受到比这略微少一些的限制，因为线程池与.NET中的所有其他内容共享。但是，您可以通过配置设置来提高线程池，但是随着您增加的线程数量越多，性能会呈指数级下降的趋势。如果您可以保证不会太多增长，理论上可以将此数字增加，然后可能只需使用.NET中的标准线程监视器来构建自己的彗星事件分派机制。
但是，在运行较新版本的IIS的.NET应用程序中确实有一线希望。您可以创建自定义
IAsyncHttpHandler。有一些在线指南可以让您了解其工作原理。通过这样做，您可以建立自己的连接池并更有效地为客户提供服务。这不是完美的解决方案，您必须自己构建大量管道。
WebSync是一个商业产品，为您包装了这个接口，并为您提供了一些高级框架组件，可供您使用。
