伺服器的負載非常大 - 每秒數百個請求。其中絕大多數是透過 SSL 進行的。
問題是，即使不涉及資料庫，第一次透過 HTTPS 向伺服器請求的回應也非常慢（例如 10 秒）。下一個請求在眨眼間就實現了。同時，無需 SSL，它就能持續快速運作。幾天前，情況發生了逆轉 - 大部分流量在沒有 SSL 的情況下很快，而在沒有 SSL 的情況下速度很慢。
我希望連線通過 SSL，但在大約 10 秒的水平缺乏活動一段時間後的第一次回應是不可接受的。我可以在 apache2 配置中更改什麼以避免第一次響應緩慢？
答案1
聽起來您在金鑰交換方面受到了 CPU 的限制。常見問題。當客戶端第一次透過 SSL/TLS 連線時，會進行金鑰交換（計算成本非常高）。完成此密鑰交換後，用戶端可以在後續通訊中重複使用在交換中獲得的密鑰。這就是為什麼透過 HTTPS 的第一個請求需要很長時間才能完成。
對於這種情況，除了添加資源之外，您無能為力。更多的CPU將加速密鑰交換的運算。更多的記憶總是好的。您也可以設定 Apache 將產生的金鑰在記憶體中保留更長時間，以避免客戶端重做金鑰交換。
您還可以透過更改密碼套件或調整密鑰長度來對效能進行一些微小的改進，但這通常不值得這麼麻煩。
如果您要在此類負載上運行較長時間，那麼卸載 SSL/TLS 計算可能是個好主意。您可以獲得一個單獨的盒子（使用您最喜歡的代理）、SSL 加速卡，甚至是專門的 SSL/TLS 卸載盒。
答案2
看起來像 DNS 問題。檢查本機上的 DNS 是否已配置且運作正常，同時檢查主機名稱查找指令在 apache 配置中設定為 off。
答案3
我能想到兩種場景：
- 檢查 Apache 的日誌並從中找出一些巧妙的東西（錯誤、訪問日誌時間戳記等）——我認為這是一個不太可能的事情
- 或者：我向 Wireshark 建議您 SSL 握手協定是如何進行的。您應該看到 10 秒過去的位置 - 在伺服器端還是在客戶端。我想打開密鑰庫或類似的東西會花費很多時間，但首先您應該嗅探網路流量中的時間戳。讓我們知道進展如何！
答案4
我發現了一個問題。我不得不關閉 KeepAlive。
每秒都有大量新連線（200-300/秒，有時更多）。他們中的大多數不需要連接保持 5 秒。結果，連線池很快就被利用了，所有新連線都必須等待舊連線在 5 秒後終止。
看來 KeepAlive 選項僅當伺服器能夠保持足夠的開啟連線而大多數使用者執行 KeepAliveTimeout 參數指定的某些操作（在我的情況下為 5 秒）時才有用。
其他情況下將其關閉實際上很有用。