NGINX でコンテンツをキャッシュする方法
NGINX は、コンテンツとアプリケーションの配信を高速化し、セキュリティを強化し、スケーラビリティを向上させる、統合されたオープンソースの高性能 Web サーバーです。 Nginx の最も一般的な使用例の 1 つはコンテンツ キャッシュで、これはウェブサイトのパフォーマンスを向上させる最も効果的な方法です。
こちらもお読みください: Linux 用のトップ 10 オープンソース キャッシュ ツール
NGINX を使用すると、アップストリーム サーバーからの応答をキャッシュするように構成することでローカル オリジン サーバーを高速化したり、コンテンツ配信ネットワーク (CDN) 用のエッジ サーバーを作成したりできます。 NGINX は、いくつかの最大規模の CDN を強化します。
キャッシュとして構成されている場合、NGINX は次のことを行います。
- 静的コンテンツと動的コンテンツをキャッシュします。
- マイクロキャッシュを使用して動的コンテンツのパフォーマンスを向上させます。
- パフォーマンスを向上させるためにバックグラウンドで再検証しながら古いコンテンツを提供します。
- Cache-Control ヘッダーなどをオーバーライドまたは設定します。
この記事では、Web サーバーを可能な限り効率的に実行するために、Linux でNGINX をコンテンツ キャッシュとして構成する方法を学びます。
前提条件:
Linux サーバーにNGINX がインストールされている必要があります。インストールされていない場合は、次のガイドに従って Nginx をインストールしてください。
- CentOS 8 に Nginx をインストールする方法
- CentOS 7 に Nginx をインストールする方法
Nginx で静的コンテンツをキャッシュする
静的コンテンツは、ページ間で同じままである (変化しない) Web サイトのコンテンツです。静的コンテンツの例には、画像、ビデオ、ドキュメントなどのファイルが含まれます。 CSS ファイルと JavaScript ファイル。
Web サイトで多くの静的コンテンツを使用している場合は、アクセスを高速化するためにブラウザーが静的コンテンツのコピーを保存するクライアント側のキャッシュを有効にすることで、パフォーマンスを最適化できます。
次のサンプル構成はうまくいきます。www.example.com
を Web サイト名の URL に置き換え、必要に応じて他のパス名を変更するだけです。
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
Nginx で動的コンテンツをキャッシュする
NGINX は、ローカル ファイル システムのどこかにある永続ディスク ベースのキャッシュを使用します。そのため、まず、キャッシュされたコンテンツを保存するためのローカル ディスク ディレクトリを作成します。
# mkdir -p /var/cache/nginx
次に、キャッシュ ディレクトリに適切な所有権を設定します。次のように、NGINX ユーザー (nginx) とグループ (nginx) が所有する必要があります。
chown nginx:nginx /var/cache/nginx
次に、以下のセクションで Nginx で動的コンテンツを有効にする方法を確認してください。
NGINX で FastCGI キャッシュを有効にする
FastCGI (または FCGI) は、PHP などの対話型アプリケーションと NGINX などの Web サーバーを接続するために広く使用されているプロトコルです。強い>。これはCGI (共通ゲートウェイ インターフェイス) の拡張です。
FCGI の主な利点は、複数の CGI リクエストを 1 つのプロセスで管理できることです。これがないと、Web サーバーは、サービスに対するクライアント要求ごとに、新しいプロセス (制御され、要求を処理し、終了する必要がある) を開く必要があります。
LEMP スタック展開で PHP スクリプトを処理するために、NGINX は FPM (FastCGI プロセス マネージャー) または を使用します。 PHP-FPM は、一般的な PHP FastCGI の代替実装です。 PHP-FPM プロセスが実行されると、NGINX は処理のためにリクエストをプロキシするように設定されます。したがって、NGINX はPHP-FPM バックエンド アプリケーション サーバーからの応答をキャッシュするように構成することもできます。
NGINX では、FastCGI コンテンツ キャッシュは、トップレベルの http{}
の fastcgi_cache_path
というディレクティブを使用して宣言されます。 NGINX 構成構造内のコンテキスト。キャッシュ用のキー (リクエスト識別子) を定義する fastcgi_cache_key
を追加することもできます。
さらに、アップストリームのキャッシュ ステータスを読み取るには、http{}
コンテキスト内に add_header X-Cache-Status ディレクティブを追加します。これはデバッグの目的で役立ちます。
サイトのサーバー ブロック設定ファイルが /etc/nginx/conf.d/testapp.conf または /etc/nginx/sites-available/testapp.conf にあると仮定します ( Ubuntu とその派生版の下で)、編集ファイルを開き、ファイルの先頭に次の行を追加します。
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
fastcgi_cache_path
ディレクティブは、次のパラメータの数を指定します。
- /var/cache/nginx – キャッシュ用のローカル ディスク ディレクトリへのパス。
- レベル – キャッシュの階層レベルを定義し、/var/cache/nginx の下に 2 レベルのディレクトリ階層を設定します。
- keys_zone (name:size) – すべてのアクティブなキーとデータ (メタ) に関する情報が保存される共有メモリ ゾーンの作成を有効にします。キーをメモリに保存すると、ディスク上のステータスを確認しなくても、NGINX がミスかヒットかを判断しやすくなり、チェックプロセスが高速化されることに注意してください。
- 非アクティブ – 指定した時間内にアクセスされなかったキャッシュされたデータが、その鮮度に関係なくキャッシュから削除されるまでの時間を指定します。この構成例の値 60m は、60 を超えてアクセスされなかったファイルがキャッシュから削除されることを意味します。
- max_size – キャッシュの最大サイズを指定します。ここで使用できるパラメーターは他にもあります (詳細については、NGINX ドキュメントを参照してください)。
fastcgi_cache_key
ディレクティブの変数については、以下で説明します。
NGINX は、リクエストのキー (識別子) を計算する際にそれらを使用します。重要なのは、キャッシュされた応答をクライアントに送信するには、リクエストにキャッシュされた応答と同じキーが必要であることです。
- $scheme – リクエスト スキーム、HTTP または HTTPS。
- $request_method – リクエスト メソッド。通常は「GET 」または「POST 」です。
- $host – これは、リクエスト行のホスト名、「ホスト 」リクエスト ヘッダー フィールドのホスト名、またはリクエストに一致するサーバー名を優先順位で指定できます。 。
- $request_uri – 完全な元のリクエスト URI (引数付き) を意味します。
また、add_header X-Cache-Status ディレクティブの $upstream_cache_status
変数は、MISS であるかどうかにかかわらず、NGINX が応答するリクエストごとに計算されます。 > (応答がキャッシュ内に見つからず、アプリケーション サーバーから取得されました) またはHIT (応答がキャッシュから提供されました)、またはその他のサポートされている値。
次に、PHP リクエストを PHP-FPM に渡す location
ディレクティブ内で、 fastcgi_cache
ディレクティブを使用して、上で定義したキャッシュをアクティブにします。
また、示されているように fastcgi_cache_valid
ディレクティブを使用して、さまざまな応答のキャッシュ時間を設定します。
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 60m;
この例のようにキャッシュ時間のみが指定されている場合、200、301、および 302 の応答のみがキャッシュされます。ただし、応答を明示的に指定したり、any (任意の応答コードに対して) を使用したりすることもできます。
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200 301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid any 10m;
Nginx での FastCGI キャッシュ パフォーマンスの微調整
応答がキャッシュされるまでに同じキーを使用してリクエストを行う必要がある最小回数を設定するには、http{}
または に
または fastcgi_cache_min_uses
ディレクティブを含めます。 >server{}location{}
コンテキスト。
fastcgi_cache_min_uses 3
「If-Modified-Since 」および「If-None-Match 」ヘッダー フィールドを含む条件付きリクエストを使用して期限切れのキャッシュ アイテムの再検証を有効にするには、 fastcgi_cache_revalidate
ディレクティブ。http{}
、server{}
、または location{}
コンテキスト内。
fastcgi_cache_revalidate on;
location ディレクティブ内の proxy_cache_use_stale
ディレクティブを使用して、オリジン サーバーまたは FCGI サーバーがダウンしているときにキャッシュされたコンテンツを配信するように NGINX に指示することもできます。
このサンプル構成は、NGINX が上流サーバーからエラー、タイムアウト、および指定されたエラーのいずれかを受信し、キャッシュされたコンテンツ内に要求されたファイルの古いバージョンがある場合、古いファイルを配信することを意味します。
proxy_cache_use_stale error timeout http_500;
FCGI キャッシュのパフォーマンスを微調整するためのもう 1 つの便利なディレクティブは、proxy_cache_use_stale
ディレクティブと連携して動作する fastcgi_cache_background_update
です。 on に設定すると、クライアントが期限切れのファイル、またはアップストリーム サーバーから更新中のファイルを要求したときに、古いコンテンツを提供するように NGINX に指示します。
fastcgi_cache_background_update on;
fastcgi_cache_lock
は、キャッシュ パフォーマンスの微調整にも役立ちます。複数のクライアントがキャッシュにない同じコンテンツをリクエストした場合、NGINX は最初のリクエストのみを上流サーバーに転送し、コンテンツをキャッシュします。応答は、キャッシュから他のクライアント要求を処理します。
fastcgi_cache_lock on;
NGINX 構成ファイルに上記の変更をすべて加えた後、ファイルを保存して閉じます。次に、NGINX サービスを再起動する前に、構成構造に構文エラーがないか確認してください。
nginx -t
systemctl restart nginx
次に、キャッシュが適切に機能しているかどうかをテストし、次のcurlコマンドを使用してWebアプリケーションまたはサイトにアクセスしてみます(初回はミスを示すはずですが、その後のリクエストはヒットを示すはずです)スクリーンショットに示されているように)。
curl -I http://testapp.linux-console.net
これは、NGINX が古いデータを提供していることを示す別のスクリーンショットです。
バイパスキャッシュへの例外の追加
fastcgi_cache_bypass
ディレクティブを使用して、NGINX がキャッシュされた応答をクライアントに送信しない条件を設定できます。また、上流サーバーからの応答をまったくキャッシュしないように NGINX に指示するには、fastcgi_no_cache
を使用します。
たとえば、クエリ文字列を含むPOST リクエストと URL を常に PHP に送りたい場合です。まず、以下のように条件を設定するif文を宣言します。
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
次に、location
ディレクティブで上記の例外をアクティブにし、fastcgi_cache_bypass
と fastcgi_no_cache
を使用して PHP リクエストを PHP-FPM に渡します。 > 指示。
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
サイトには、コンテンツ キャッシュを有効にしたくない部分が他にもたくさんあります。以下は、nginx.com ブログで提供されている、WordPress サイトのパフォーマンスを向上させるための NGINX 構成の例です。
これを使用するには、環境内に存在するものを反映するように変更 (ドメイン、パス、ファイル名など) を加えます。
fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com;
index index.php;
access_log /var/log/NGINX/example.com.access.log;
error_log /var/log/NGINX/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
NGINX でプロキシ キャッシュを有効にする
NGINX は、他のプロキシ サーバーからの応答のキャッシュもサポートしています (proxy_pass
ディレクティブで定義されています)。このテスト ケースでは、Node.js Web アプリケーションのリバース プロキシとして NGINX を使用しているため、NGINX を Node.js アプリケーションのキャッシュとして有効にします。ここで使用されるすべての構成ディレクティブは、前のセクションの FastCGI ディレクティブと同様の意味を持っているため、再度説明しません。
プロキシ サーバーからの応答のキャッシュを有効にするには、トップレベルの http{}
コンテキストに proxy_cache_path
ディレクティブを含めます。リクエストをキャッシュする方法を指定するには、次のように proxy_cache_key
ディレクティブを追加することもできます。
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m;
proxy_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_min_uses 3;
次に、location ディレクティブでキャッシュをアクティブにします。
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
NGINX がキャッシュされたコンテンツを送信せず、上流サーバーからの応答をまったくキャッシュしない条件を定義するには、proxy_cache_bypass
と proxy_no_cache
を含めます。
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache $http_pragma $http_authorization;
プロキシ キャッシュ パフォーマンスの微調整
次のディレクティブは、プロキシ キャッシュのパフォーマンスを微調整するのに役立ちます。これらは、FastCGI ディレクティブと同じ意味を持ちます。
proxy_cache_min_uses 3;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_background_update on;
proxy_cache_lock on;
詳細およびキャッシュ構成ディレクティブについては、2 つの主要モジュール ngx_http_fastcgi_module および ngx_http_proxy_module のドキュメントを参照してください。
追加リソース: NGINX コンテンツ キャッシュと WordPress パフォーマンスを改善するためのヒント。