Rails的頁面緩存與HTTP反向代理緩存

Question

我一直在趕上Scaling Rails截屏視頻。在包含高級HTTP緩存（使用反向代理緩存（如Varnish和Squid等））的episode 11中，他們建議只有在已經耗盡了Rails應用程序中頁面，操作和片段緩存的可能性時才考慮使用反向代理緩存以及memcached等，但這與這個問題無關）。

我不明白的是，如何使用HTTP反向代理緩存可以爲已經使用頁面緩存的應用程序提供性能提升。爲了簡化問題，讓我們假設我在這裏討論單個主機。

這是我的兩種技術是如何工作的理解（也許我是錯的）：

• 頁面緩存Rails的過程最初擊中，然後產生直接由服務的靜態HTML文件用於後續請求的Web服務器，只要該請求的緩存有效即可。如果緩存已經過期，則Rails會再次被點擊，並且爲更新的內容重新生成靜態文件，以便爲下一個請求做好準備

• 使用HTTP反向代理緩存時，Rails進程會在代理需要確定內容陳舊或不陳舊。這是通過使用各種HTTP標頭完成的，如ETag,Last-Modified等。如果內容是新鮮的，Rails將響應代理服務器的HTTP 304 Not Modified，並且代理服務器將其緩存的內容提供給瀏覽器，或者甚至更好地用它自己的響應HTTP 304.如果內容是陳舊的，然後Rails的提供更新的內容到緩存它的代理，然後將其用於瀏覽器

如果我的理解是正確的，那麼不會在更短的命中頁面緩存結果到Rails進程？確定內容是否過時並不是所有情況，這意味着比反向代理緩存更好的性能。爲什麼你可以同時使用這兩種技術？

Answer 1

你說得對。

考慮它的唯一原因是如果你的apache套件過期頭。在這個配置中，代理可以從apache中取出一些負載。

話雖如此，apache靜態與代理緩存在rails領域幾乎是無關緊要的。它們都是天文速度快的。

你會得到的好處是你的無頁面可緩存的東西。

我更喜歡在頁面緩存（ala heroku）上使用代理緩存，但那只是我和一個離題。

Answer 2

當使用prefork MPM時，一個好的代理緩存實現（例如Squid，Traffic Server）比Apache更具可擴展性。如果你使用worker MPM，Apache是​​可以的，但是代理在高負載（每秒數萬次請求）時仍然可以擴展。

Answer 3

光油例如有一個功能，當對同一個URL（不在緩存中）的同時請求排隊並且只有單個/第一個請求實際上碰到後端時。這可以防止傳統頁面緩存場景中幾乎不可能解決的一些令人討厭的狗樁事件。

Answer 4

在只有一個應用程序服務器的設置中使用反向代理似乎有點矯枉過正IMO。 在具有多個應用程序服務器的配置中，反向代理（例如清漆等）是頁面緩存的最有效方式。

思考與2的應用服務器的設置的：

• 「用戶鮑勃（重定向到節點「A」）發佈一個新的消息，該頁面被過期並重新創建節點「A」。

• 用戶'Cindy'（重定向到節點'B'）請求應該出現'Bob'的新消息的頁面，但她看不到新消息，因爲節點'B'上的頁面沒有過期並重新創建。

這個併發問題可以通過反向代理解決。