我是開發營運 Web 開發人員，我的網站在 AWS 上的負載平衡器後面運行兩個 ec2.small。
最近，我們看到每秒 3-4 個請求導致我們的客戶網站癱瘓。
該網站已關閉，並且在多次伺服器重新啟動和錯誤日誌掃描可能導致問題的任何腳本後不會恢復，即使最近沒有推送任何變更。
打開負載平衡器日誌記錄後，我發現對單一頁面的數千個請求來自一個 IP 位址。
我們使用 X-forwarded-for 將請求從負載平衡器轉送到處理請求的伺服器，並使用 .htaccess 規則阻止 IP。
在與客戶 IT 部門溝通時，他們被告知造成大量請求的 IP 位址實際上是其內部公司電腦之一。
負責的機器被遠端重新啟動，所有請求都停止了。網站恢復上線。
官方對此的解釋是「電腦出了問題」。
Web 瀏覽器或 Windows 機器是否有可能每秒向負載平衡網頁發出 3-4 個請求，並將其關閉 5 個多小時？
請求如下：
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
答案1
當然這是可能的——儘管這取決於許多因素：
1）聽起來伺服器端應用程式存在並發問題。可能值得一看的是應用程式伺服器是否是瓶頸，或者是否是上游（例如資料庫）和應用程式伺服器由於 apache 配置刷新線程不夠快而記憶體不足。如果是應用程式伺服器，可能值得進行一些調整 - 在 ELB 之外啟動一台相同的機器，並使用 JMeter 向其施加一些負載以找出瓶頸。
如果是資料庫，您也許可以使用 memcache/elasticache （因為看起來您正在檢索特定物件）來快取實際查詢。這樣資料庫連線反應速度很快，Apache 可以快速回應，並殺死線程而不是填滿應用程式機器的記憶體池。
如果你真的感覺很脆弱，你可以將 Varnish 放在上游，以 1-5 秒的 TTL 快取請求，以防止主要請求氾濫。但要小心，因為 VCL 是無情的，可能會導致重大問題和痛苦（緩存中毒/洩漏）。
2）至於「主體」機器本身。顯然它可能已洩露 - 絕對應該對其進行調查。我會讓你決定 IT 人員是否誠實 - 這不屬於伺服器故障的範圍。
假設它沒有受到損害，它可能是一些錯誤的 JavaScript 程式碼 - 如果您進行輪詢刷新並且以某種方式修改了計時參數，它很可能開始每秒發送許多請求。同樣，JS 可能表現良好，但此人可能打開了 25 個選項卡並在晚上回家 - 如果每個選項卡每 5 秒發送 1 個請求，則為 5 個請求/秒。