在我的系統上打開和關閉請求需要很長時間

已編輯：我的 AWS 系統中有問題。每幾個請求幾乎都需要 130 秒的時間來回答。當我說一些時，我的意思是 5 到 25 左右。通常，如果您取消慢速請求並再次發送，它只會快速響應。我還注意到任何請求都會發生這種情況，而不僅僅是特定請求。伺服器和後端看起來並沒有超載。系統如下：

ALB with sticky sessions | 2 Web servers | DB on RDS

系統在大多數時候使用 curl 時響應良好，但是當它需要很長時間時，這是響應輸出：

這是任何 URL 上的 curl 測量時間。

   time_namelookup:  0.004136
      time_connect:  130.117558
   time_appconnect:  130.125254
  time_pretransfer:  130.125340
     time_redirect:  0.000000
time_starttransfer:  130.172553
                   ----------
        time_total:  130.172615

除了 之外，從time_connect頁面載入之後的意義上說，請求很好。系統正常響應時間小於0.5秒。

我正在閱讀有關此的內容，並且文件表明time_connect，與

“從客戶端的角度來看，time_connect 是 TCP 三次握手。它在客戶端發送 ACK 後立即結束 - 它不包括該 ACK 到達伺服器所花費的時間。它應該接近往返時間(RTT) 到伺服器…"

這是從這裡拍攝的。

補充：系統本身是 nginx-Python，執行在 ec2 實例上，RDS 上有 MySQL 數據庫，它提供來自 s3 的靜態內容，使用者也可以上傳自己的文件。來自本地主機上的伺服器（nginx-python ec2 實例） curl 總是很好，它永遠不會花費很長時間。這讓我相信這與 LB 和在 python 主機上監聽的 nginx 有關。

補充：我也試過只在後端留下一台機器，問題並沒有消失。

我在 AWS Cloudwatch、應用程序日誌或數據庫監控上找不到任何有意義的東西。關於我應該研究什麼或如何解決此問題的任何想法？

編輯 3 感謝下面的評論：

# curl -v -I -L -k -w "@time.txt" -s "https://my-site.com/url/"
*   Trying "
*   Trying IP.ONE.from.AWS...
* connect to IP.ONE.from.AWS port 443 failed: Connection timed out
* TCP_NODELAY set
* Connected to my-site.com (IP.TWO.from.AWS) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt

IP-ONE-from-AWS 和 IP-TWO-from-AWS 是來自我應該連接的 AWS 區域的 IP。

您已將負載均衡器放置在一個公有子網和一個私有子網中，這是一種無效配置，並且會導致與您觀察到的行為類似的行為，因為一個均衡器為其所連接的每個子網分配了至少一個公有 IP。 .. 但根據定義，公共 IP 地址不起作用，除非子網是公共子網。

面向 Internet 的負載均衡器只需連接到公共子網。它們不需要附加到它們背後的實例部署（或應該）部署的私有子網，或任何其他私有子網。

或者，您可能打算將平衡器放置在兩個公共子網中，但其中一個具有錯誤配置的 VPC 路由表或網路 ACL，它具有相同的淨效應，並且在您連接到該 IP 地址時會阻止流量。

引用自：https://serverfault.com/questions/1023408