4
感謝Godfrey Chan對我從他那裏得到的有益見解。他指出，有一個Rack中間件可以爲我提供更準確的響應中X-Runtime HTTP標頭中Rails請求的時間定時，與日誌中報告的時間相比較（Completed in XXXms ... ）。當nginx用作代理時，爲什麼Rails中間件開銷如此之高？
這是我從我的測試中獲得：
1 - 訪問網址指向Rails應用在Chrome：
- X-運行時間：25ms的
- Chrome的 「等待」 時間：27ms
- 報告的時間在Rails日誌格式：在7毫秒完成200 OK（瀏覽次數：0.9ms |續集：3.0毫秒）
2 - 訪問同一個網址，但使用nginx的與proxy_pass，也是在Chrome：
- X-運行時間：84ms
- Chrome的 「等待」 時間：88ms
- 完成200 OK在7毫秒（瀏覽次數：爲0.8ms |續集：2.9ms）
3 - 從Chrome的開發者工具複製捲曲地址和捲曲-I運行它：
- X-運行時間：105ms（有時上升到400毫秒）
- 完成在88ms 200 OK（瀏覽次數：2.0ms |續集：5.5ms）
這些定時是非常一致的，當我嘗試了他們很多次。
任何想法，爲什麼如果Rails通過nginx proxy_pass需要更長的時間來服務相同的請求？我知道Curl不能利用保持活躍等功能，但我相信nginx能夠獲得它的優勢。但無論如何，X-Runtime標題不應該考慮打開連接的時間，對吧？
對我而言無顯着性差異，僅約4-10ms。也許你可以分享你的nginx配置？ – htanata
禁用了一些之前的過濾器（如Devise的authorize_user和其他用於記錄的目的）的nginx開銷是非常小的...我會稍後再嘗試一些實驗，看看是否可以跟蹤哪些過濾器明確受到nginx影響我會在那時發佈更多細節。 – rosenfeld
我不明白。我重新啓用了所有過濾器，並使用curl -I -w％{time_connect}：％{time_starttransfer}：％{time_total} \\ n加上從Chrome複製的其他參數運行測試，現在我得到快速的結果，即使使用nginx。在使用nginx或localhost：3000時，我看不出有什麼明顯的區別：所以我認爲我應該關閉這個問題，因爲我不能再現它... – rosenfeld