2 回答
我已经通过异步 Http 处理程序实现了一个反向代理，用于基准测试（作为我博士论文的一部分），并且遇到了和你一样的问题。
为了扩展，必须将 processModel 设置为 false 并微调线程池。我发现，与有关 processModel 默认值的文档所说的相反，当 processModel 设置为 true 时，许多线程池没有正确配置。maxConnection 设置也很重要，因为如果限制设置得太低，它会限制您的可伸缩性。请参阅http://support.microsoft.com/default.aspx?scid=kb;en-us;821268
关于由于套接字上的 TIME_WAIT 延迟而导致您的应用程序耗尽端口的问题，我也遇到了同样的问题，因为我在 240 秒内从一组有限的机器中注入了超过 64k 个请求的流量。我将 TIME_WAIT 降低到 30 秒，没有任何问题。
我还错误地将代理对象重用到多个线程中的 Web 服务端点。虽然代理没有任何状态，但我发现 GC 在收集与其内部缓冲区（String [] 实例）相关的内存时遇到了很多问题，这导致我的应用程序内存不足。
您应该监控的一些有趣的性能计数器是与 ASP.NET 应用程序类别下的排队请求、执行中的请求和请求时间相关的计数器。如果您看到排队的请求或执行时间很短但客户端看到很长的请求时间，那么您的服务器中存在某种争用。还要监视 LocksAndThreads 类别下的计数器以查找争用。
由于异步请求使 tcp 套接字保持更长时间，也许您需要查看 web.config 中连接管理中的maxconnection属性？请参考此链接： http: //support.microsoft.com/default.aspx ?scid=kb;en-us;821268
我们遇到了类似的问题并调整了这个参数来解决我们的问题。也许这会对你有所帮助。
编辑：此外，根据过去的经验，许多 TIME_WAIT 表明代码中存在连接泄漏。可能的原因： 1) 未处理使用的连接。2) 连接池的错误实现。