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

Question

我一直在追趕Scaling Rails的截屏視頻。 在第11集中 ，它涵蓋了高級HTTP緩存（使用反向代理緩存，如Varnish和Squid等），一旦你已經用盡了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（不在高速緩存中）的同時請求排隊並且只有單個/第一個請求實際到達后端時，Varnish具有一個功能。 這可以防止在傳統的頁面緩存場景中幾乎不可能解決的一些討厭的狗堆案例。

Answer 4

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

想想有2個應用服務器的設置：

• 用戶'Bob'（重定向到節點'A'）發布新消息，頁面過期並在節點'A'上重新創建。

• 用戶'Cindy'（重定向到節點'B'）請求顯示來自'Bob'的新消息的頁面，但是她看不到新消息，因為節點'B'上的頁面未過期並重新創建。

這種並發問題可以通過反向代理來解決。