我们的 IIS 网站将其最大并发连接数设置为 4294967295。我们的 Web API 应用程序正在记录它向 Application Insights 提供的所有请求,并且两者似乎不匹配。似乎在 Insights 中快速得到服务的调用在 IIS 的日志中似乎没有快速完成。
什么可能导致这种情况,这是否表明 IIS 连接不足,即使最大值设置得高得离谱?
换一种说法(在阅读@zakima 的评论后):我应该寻找什么来识别在 IIS 中延迟的请求在它们到达应用程序本身之前或之后?
我们的 IIS 网站将其最大并发连接数设置为 4294967295。我们的 Web API 应用程序正在记录它向 Application Insights 提供的所有请求,并且两者似乎不匹配。似乎在 Insights 中快速得到服务的调用在 IIS 的日志中似乎没有快速完成。
什么可能导致这种情况,这是否表明 IIS 连接不足,即使最大值设置得高得离谱?
换一种说法(在阅读@zakima 的评论后):我应该寻找什么来识别在 IIS 中延迟的请求在它们到达应用程序本身之前或之后?
最大并发连接数默认为 4294967295,这是一个惊人的数字。但这并不意味着该站点可以具有执行4294967295个并发连接的能力。
假设4294967295个并发连接同时到来,IIS不会立即启动4294967295个线程来处理,因为这是不现实的。对于连接的处理,IIS 具有“最大并发工作线程”限制。从某些来源来看,这个数字与操作系统有关。如果IIS第一次只能启动10个工作线程来处理,那么其他4294967285必须排队。
换句话说,4294967295 表示默认情况下允许从 http.sys 模块到站点的最大并发连接数。然后这些请求将到达 IIS 的每个模块并最终到达应用程序。
如果要查看 IIS 的真实最大并发连接数,请参考这篇文章使用性能监视器。
关于如何监控 IIS 之前或之后延迟的请求,我建议您使用失败的请求跟踪。这是我的 asp.net 应用程序的失败请求跟踪日志示例。