我在IIS 7.0上部署了一个Web应用程序。大量用户可以访问该应用程序并操作大数据..我的问题与HTTP Keep-Alive选项有关，默认情况下设置为true。
将HTTP Keep-Alive设置为false或true是一种更好的方法。
如果是真的是使用超时的好方法吗？
答案 0 :(得分：7)
KeepAlive通常应用于处理紧跟 HTML请求的请求。让我们说在第一次访问你的网站时，我得到一个包含5个css，5js和25个图像的HTML页面，我将使用我仍然活着的HTTP连接来请求这些东西（好吧，取决于浏览器，我可能会使用3连接加速这些事情。）
为了处理这个事实，我们通常使用 2s或3s 的Keepalive。拥有更长的keepalive意味着连接正在等待用户可能请求的下一页。这可能是一种有效的思考方式，下次用户想要一个页面时，我们将避免浪费时间建立HTTP连接（这可能是请求/响应时间中最长的部分）。但对于您的服务器而言，服务器处理的大部分HTTP连接都是正在做......没有什么。并且您将达到 MaxConnection （W3SVC / MaxConnections，默认为10的荒谬），连接什么都不做。特别糟糕。如此长的keep-alive需要大型Web服务器，并且只有在您的应用程序真正需要它时才应该使用它。
如果您在“经典网站”中使用Keepalive，则必须更改连接超时（默认为2分钟）。在Apache中，您将有2个设置，一个keepalive tiemout（默认为5秒）和一个连接超时（2分钟）。在IIS中，似乎超时设置用于两者。所以不要把它设置为2s（客户端发送请求的时间会很慢），但10s之类的东西就足够了。现在一个响应是禁止Keep-Alive，并使浏览器打开更多连接。另一个响应是使用现代的网络服务器（例如nginx或cherokee），它以比Apache或IIS更优雅，更无资源的方式处理保持连接。
即使您不使用Keepalive，等待客户端超时2分钟的原因是什么？它确实太高了，降低这个值就像60s。
然后你应该检查几个与超时（ConnectionTimeout, HeaderWaitTimeout, MinFileBytesPerSec）相关的设置以及注册表中performances settings上的这个好的响应。
答案 1 :(得分：3)
本文将带来更多见解，不要忘记查看“我们如何修复它？”部分 http://mocko.org.uk/b/2011/01/23/http-keepalive-considered-harmful/
答案 2 :(得分：0)
我认为让所有用户连接不是一个好主意。
因为：
使用连接超时（我们可以最多5分钟）
但是：如果您的应用程序是实时聊天 - 您应该保持所有连接。这样可以更好地使用Ajax Long Polling Request + Node JS +一些快速的nosql db来存储聊天消息。