用於 css/js/images 的專用 Nginx 伺服器非常酷，但圖片載入速度很慢。為什麼？

Question

我們公司有三台專用伺服器，一台運行 Nginx 並充當 Web 伺服器 (php)，另一台處理 MySQL 和 Memcached，另一台用於提供靜態檔案：css、js 和映像。

所有伺服器在 New Relic 上都表現出色，特別是靜態檔案伺服器：

• CPU持續低於10%
• 網路 IO 接收速度非常低，傳輸速度最高約為 10 Mb/s，但 MySQL 伺服器具有相同的規格，並且通常峰值速度為 20 mb/s，因此懷疑這是一個問題。
• 平均負載低於 0.5

問題是，在高峰時段，顯然某些使用者載入圖片（大小可能為 100kb - 200kb）需要很長時間（很多秒，有時甚至長達一分鐘，而通常只需要幾秒鐘）最差秒）。

知道我們能做什麼嗎？理想情況下，如果 CPU、RAM 或頻寬均未達到任何限制，則不應發生這種情況。

我們應該關注（並且可能需要更改）的任何關鍵 Nginx 配置參數？

Answer 1

我能想到兩種可能性。

1. 您的磁碟已達到 I/O 上限。
2. 您已達到 nginx 中的工作線程限制。看著那（這工人_*來自核心模組的配置參數和工人連接從事件模組中找出如何促進這一點。預設是單一工作進程，它是單執行緒的，因此如果您在多 CPU 平台上運行，那麼您絕對應該增強它。即使您使用的是單CPU 機器，您也將受益於在提供靜態資源的電腦上提高此數字，因為您將在其他任何事情之前就受到磁碟I/O 限制，並且其他線程可以在同時接收和處理更多請求。

Answer 2

我們可以坐在這裡猜測您整天的瓶頸在哪裡，但一些更一般的建議將幫助您更快地自己找到它。

jeffatrackaid 寫道昨天這個答案這是一個更簡潔的版本我很久以前寫的。我建議先閱讀這些內容，以幫助理解效能調試是如何完成的。

在你的情況下，我會先使用 Firebug 來確定高峰時段請求的哪一部分變慢。如果頻寬不是真正的問題，那麼這應該排除頻寬。請查看 Firebug 的「Net」部分，看看請求的哪一部分在快時間和慢時間之間發生變化。

接下來，我會在其中一個緩慢的時間段內對其中一個 nginx 工作線程運行帶有-t和選項的 strace。-T對其輸出的分析應該可以準確地告訴你 nginx 哪裡變慢了。將 strace 輸出寫入文件，然後在文件上使用less或grep來識別花費很長時間的系統呼叫很有用。

您可能會從-cstrace 選項中獲得一些用處。

一旦您確定了緩慢的系統調用，找出需要更改哪個 nginx 參數仍然需要做一些工作，但您應該可以順利進行了。如果您需要該部分的協助，請回來詢問更具體的問題。

如果結果是基於檔案的系統調用，請務必向後查看跟踪，直到找到它正在等待的檔案。這將是一個很大的暗示。