我想我知道这里发生了什么，但是希望您能通过确认和/或阅读材料将其“思考”变成“知道”，即Tl，DR部分中帖子结尾处的实际问题：
设想：
我正在测试我的MVC应用程序，以了解内部组件之一停滞的情况（与数据库的连接超时）。
在我的一个网页上有一个Jquery数据表，它每隔半秒通过ajax查询更新-我当前的任务是，如果该数据请求超时，则显示正确的错误。因此，为了进行测试，我制作了一个存储过程，要求DB服务器在响应之前等待3秒，这比配置的超时设置长-因此，这可以确保我可以捕获超时异常。
我正在使用一个客户端的Chrome浏览器进行测试。在VS2013 IIS Express中调试应用程序
问题：激活我有目的的减速后，没想到会出现以下症状：
1）使用绑定的数据表启动页面后，应用程序在处理来自客户端浏览器的所有请求时速度变慢-还有3个其他组件发送ajax更新请求，与我有意破坏的请求并行，并且同样的减速也适用于我在Web应用程序中执行的任何会生成请求的操作（例如，导航到其他页面）。浏览器的调试器显示请求是按时发送的，但是服务器端的相应断点要晚得多（延迟超过10秒甚至几分钟）。
2）即使我关闭了应用程序的选项卡，我的服务器仍保持处理请求。我关闭了浏览器，确保chrome.exe进程已终止，但是各种Controller动作的断点仍然在20分钟后被击中-大多数情况下，这些动作是通过自动循环来自多个页面的Ajax请求而“触发”的在我的测试期间试图访问。在我尝试导航的主页上也遇到断点。在第二个测试中，我使用RawCap监视器的环回接口来确保实际上没有任何请求仍在后台运行。
我想通过另一种解释来证实或否定理论：
因此，以上场景以服务器无法处理的频率发出循环请求-客户端数据表循环每0.5秒发送一次请求，而每个请求至少要花费3秒来生成超时。而且显然在IIS Express中某处必须限制它能够处理的并发请求数量...
令我感到惊讶的是，我有点假设如果达到了该限制（我也假设存在），那么请求将被拒绝-相反，它们似乎排队了绝对无用的时间，以后再处理-我的意思是，在什么情况下半小时后处理排队的Web请求会有用吗？
所以到目前为止，我的问题是：
Tl，DR问题：
IIS Express（Visual Studio 2013附带）是否有并发连接限制？
如果是：{此限制可在某处配置，如果是，在哪里？
IIS如何表达处理达到该限制的情况-处理是否也可以在某个地方配置？（我的意思是喜欢排队vs.立即错误，例如服务器繁忙）}
如果不是：{当请求的处理速度超出处理速度时，服务器如何处理方案？可以在任何地方配置该处理方案吗？}
此处-http: //www.iis.net/learn/install/installing-iis-7/iis-features-and-vista-editions
我发现IIS7至少允许无限数量的同步连接，但是如果服务器的速度不足以处理所有请求，那该如何实际工作呢？可以在任何地方配置限制，以及如何处理该限制吗？
将不胜感激上面的在线阅读材料的任何链接。
首先，这是一个简短的Web服务器101。生产级Web服务器是多线程的，大约一个线程=一个请求。通常，您会看到Web服务器的某种设置，称为“最大请求数”，这又大致对应于它可以产生多少个线程。每个线程在CPU和RAM方面都有开销，因此，给定正在运行的计算机所拥有的资源，可以产生多少个Web服务器是一个非常实际的上限。
当Web服务器达到此限制时，它不会开始拒绝请求，而是会在线程释放后将请求排队以进行处理。例如，如果Web服务器的最大请求数为1000（典型值），并且突然受到1500个请求的轰炸。前1000个将立即处理，另外500个将排队，直到一些初始请求得到响应，从而释放线程并允许处理一些排队的请求。
这里的一个相关主题区域是async，它在Web应用程序的上下文中，允许线程在处于等待状态时返回到“池”。例如，如果您正在使用API，则在发送请求和从API获取响应之间通常要等待一段时间（通常是由于网络延迟）。如果您以异步方式进行处理，则在此期间，线程可能会返回到池中以处理其他请求（例如，上一个示例中的500个排队的请求）。当API最终响应时，将返回一个线程以完成对请求的处理。异步允许服务器通过使用线程来更有效地处理资源，否则线程将处于空闲状态以处理新请求。
然后是客户端-服务器的概念。在HTTP之类的协议中，客户端发出请求，而服务器响应该请求。但是，两者之间没有持久的联系。（从HTTP 1.1开始这是不正确的。客户端和服务器之间的连接有时会保留，但这只是为了允许更快的将来请求/响应，因为启动连接所花费的时间不是一个因素。但是，没有在这种情况下，仍会持续进行有关客户端/服务器状态的真正持续通信）。这里的主要要点是，如果客户端（例如Web浏览器）将请求发送到服务器，然后客户端被关闭（例如关闭浏览器中的选项卡），则该事实不会传达给服务器。服务器只知道它收到了一个请求，必须响应，然后响应，即使从技术上讲，另一端也没有接收任何东西，甚至更多。换句话说，仅因为浏览器选项卡已关闭，并不意味着服务器将停止处理请求并继续前进。
然后有超时。客户端和服务器都将具有一定的超时值。Internet的分布式特性（通过TCP / IP和HTTP等协议启用）意味着网络中的节点被认为是瞬态的。没有持久的连接（除了上面的相同说明），在发出请求的客户端和响应请求的服务器之间可能会发生网络中断。如果客户/服务器没有为此计划，他们可以坐在那里永远等待。但是，这些超时时间可能相差很大。服务器通常会在30秒内响应请求而超时（尽管可能会无限期设置）。诸如Web浏览器之类的客户端往往更宽容一些，在某些情况下超时时间为2分钟或更长时间。服务器超时后，该请求将被中止。取决于为何发生超时，客户端可能会收到各种错误响应。但是，当客户端超时时，通常不会向服务器发送任何通知。这意味着，如果服务器的超时时间大于客户端的超时时间，则即使客户端已经继续运行，服务器也将继续尝试响应。关闭浏览器选项卡可能会被视为客户端立即超时，但是服务器仍然是最明智的选择，并且会继续尝试执行其工作。
所以，所有这些归结为这个。首先，在进行长轮询（这是通过每隔一定时间间隔重复提交AJAX请求所做的事情）时，您需要构建一个取消方案。例如，如果最后5个请求已超时，则至少应在一段时间内停止轮询。更好的办法是让一个AJAX请求的响应启动下一个。因此，除了setInterval可以使用之外，您还可以使用setTimeout并让AJAX回调启动它。这样，请求只有在链条未中断的情况下才继续。如果一个AJAX请求失败，则轮询将立即停止。但是，在这种情况下，您可能需要一些后备才能在一段时间后重新启动请求链。这样可以防止不断用新请求轰炸您已经故障的服务器。同样，应该继续有一些向上的时间限制。如果用户连续数天不使用该选项卡，那么您是否真的应该在所有时间内一直在轮询服务器？
在服务器端，您可以将异步与取消令牌一起使用。这有两件事：1）为您的服务器提供更多的喘息空间来处理更多请求，以及2）如果请求的某些部分超时，则提供一种取消请求的方式。有关此信息的更多信息，请参见：http : //www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4#CancelToken
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句