プロジェクトのWebスタックを次のように再構築している最中です：nginx-> haproxy->多くの（apache / passenger rails）インスタンス
目標のいくつかは次のとおりです。
- ページキャッシュの単一の場所（現在、各Apacheマシンのレールを介して行われています）
- より高速な静的コンテンツ
- 内部パイプラインからSSLを削除する
- ip logging（以前はtcpモードでhaproxyを実行したために失われました）
画像/スタイルシート/ JavaScriptアセットは、適切なヘッダーとともにキャッシュキャッシュされます。ページキャッシングは内部パラメーターに基づいており、一般的なキャッシュコントロールに応答するべきではありません。これらの目的を達成するために、構成は次のようになります。
server {
...
location /really_slow_dynamic_content/ {
root /var/www/tmp;
error_page 404 = @fetch;
}
location @fetch {
internal;
proxy_pass haproxy_ip;
proxy_store /var/www/tmp${uri}_cache.html;
proxy_store_access user:rw group:rw all:r;
}
location /assets/ {
proxy_pass haproxy_ip;
proxy_cache assets;
}
location / {
proxy_pass haproxy_ip;
}
}
私はそれほどシステム管理者ではありません。役立つ可能性のある代替案、微調整、追加機能がたくさんあることを知っています。また、proxy_cacheとproxy_storeの違いもよくわかりません。だから私の実際の質問に...
アセットをnginxマシンに移動するまで、アセットにproxy_cacheを使用し、遅い動的コンテンツにproxy_storeを使用することには意味がありますか？
また、考慮すべき他の考慮事項やソフトウェアがある場合は、それらについて聞いてみたいと思います。ありがとうございました！
この質問を投稿してから、私が使用した初期設定ではストアがまったく使用されておらず、公式のwikiの例（semi？）のerror_pageと内部設定は厳密にはオプションではありませんでしたそれは機能しているようで、機能している設定はこの質問のより良い遺産のようです）。したがって、ストアを使用してフルページを作成するのが遅い（そしてまれに更新される）こと、および画像、JavaScriptなどの実際のキャッシュを使用することは、かなりうまく機能しているようです。少なくとも私の問題を追跡するための手掛かりを与えてくれたので、私は1つの回答を受け入れますが、2つのディレクティブが意図された方法で使用されているかどうかはまだわかりませんかどうか（まあ、少なくともストアに関しては、キャッシュはもう少し明白に思えます）。