HTTP 在大型 Web 應用程序中保持活動狀態
我有一個通過 IIS 7.0 部署的 Web 應用程序。該應用程序可供大量使用者訪問並處理大量數據..我的問題是關於預設設置為 true 的 HTTP Keep-Alive 選項。
將 HTTP Keep-Alive 設置為 false 或 true 是更好的方法嗎？
如果是真的是使用超時的好方法嗎？
KeepAlive 通常應該用於處理緊跟在 HTML 請求之後的請求。假設在第一次訪問您的網站時，我得到了一個包含 5 個 css、5js 和 25 個圖像的 HTML 頁面，我將使用我仍然存在的 HTTP 連接來請求這些東西（嗯，取決於瀏覽器，我可能會使用3連接來加速這些事情）。
為了處理這個事實，我們通常使用2s 或 3s的 Keepalive 。擁有更長的保活意味著連接正在等待使用者可能請求的下一頁。這可能是一種有效的思維方式，下次使用者想要一個頁面時，我們將避免浪費時間建立 HTTP 連接（這可能是請求/響應時間中最長的部分）。但是對於您的伺服器，這意味著由伺服器處理的大多數 HTTP 連接都在做……什麼都沒有。你將達到你的MaxConnection（W3SVC/MaxConnections，荒謬的預設值為 10），而連接什麼都不做。特別糟糕。So long keep-alive 需要大型網路伺服器，並且只有在您的應用程序真正需要時才應該使用它。
如果您在“經典網站”中使用 Keepalive，則必須更改連接超時（預設為 2 分鐘）。在 Apache 中，您將有 2 個設置，一個 keepalive tiemout（預設為 5 秒）和一個連接超時（2 分鐘）。在 IIS 中，似乎兩者都使用了超時設置。所以不要將它設置為 2 秒（發送請求的客戶端真的很慢會超時），但像 10 秒這樣的時間可能就足夠了。現在一種響應是禁止 Keep-Alive，並使瀏覽器打開更多連接。另一個響應是使用現代網路伺服器（例如 nginx 或 cherokee），它以比 Apache 或 IIS 更優雅和無資源的方式處理保持連接。
即使不使用 Keepalive，客戶端超時等待 2 分鐘的原因是什麼？它肯定太高了，將此值降低到 60 左右。
然後你應該檢查幾個與超時相關的設置（ConnectionTimeout、HeaderWaitTimeout、MinFileBytesPerSec ）和系統資料庫中性能設置的這個很好的響應。