Nginxキャッシュのクリーニング

デフォルト値: なし使用フィールド: http、サーバー、場所キャッシュ ゾーンの名前を設定します。同じゾーンを別の場所で使用できます。 0.7.48 以降、キャッシュはバックエンドの「Expires」、「Cache-Control: no-cache」、「Cache-Control: max-age=XXX」などに従います。ただし、現在、nginx は、「private」や「​​no-store」などの一部のキャッシュ制御ディレクティブを無視します。同様に、nginx は、一部のプライベート データが保護されないように、キャッシュ プロセス中に「Vary」ヘッダーを処理しません。すべてのユーザーに表示されるようにするには、バックエンドで「no-cache」または「max-age=0」ヘッダーを設定する必要があります。そうしないと、proxy_cache_key に $http_cookie_xxx などのユーザー指定のデータが含まれます。これを防ぐには、proxy_cache_key の Cookie 値の一部を使用します。プライベート データがキャッシュされないように、プライベート データとパブリック データを分離して場所を指定できます。 キャッシュ ディレクティブはプロキシ バッファー (バッファー) に依存します。proxy_buffers がオフに設定されている場合、キャッシュは有効になりません。

2 proxy_cache_key

構文: proxy_cache_key 行;
デフォルト値: $scheme$proxy_host$request_uri;
使用されるフィールド: http、server、location
ディレクティブは、キャッシュに含まれるキャッシュ キーを指定します。

proxy_cache_key "$host$request_uri$cookie_user";

proxy_cache_key "$scheme$host$request_uri";

3 proxy_cache_path

構文: proxy_cache_path path [levels=number] key_z [inactive=time] [max_size=size];デフォルト値: None使用フィールド: http direct指定する必要がありますキャッシュ パスおよびその他のパラメータ。キャッシュされたデータはファイルに保存されます。キャッシュされたファイル名とキーは、プロキシ URL の MD5 コードです。レベルパラメータは、キャッシュされたサブディレクトリの数を指定します。例:

proxy_cache_path /data/nginx/cache levels=1:2 keys_z/td>

ファイル名は次のようになります: /data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c すべてのアクティブなキーとメタデータは共有ディレクトリに保存されます。メモリ領域。この領域は、keys_zone パラメータで指定されます。inactive パラメータで指定された時間内にキャッシュされたデータが要求されない場合、デフォルトの inactive は 10 分です。 キャッシュ マネージャー プロセスは、max_size パラメーターで定義されたディスクのキャッシュ サイズを制御し、そのサイズを超えると、最も使用されていないデータが削除されます。 領域のサイズは、キャッシュされたページ数に比例して設定されます。ページ (ファイル) のメタデータ サイズは、FreeBSD/i386 では 64 バイト、FreeBSD/amd64 では 128 バイトです。領域がいっぱいの場合 鍵取得後、LRU（最も最近使用されていないアルゴリズム）に従って処理されます。 proxy_cache_path と proxy_temp_path は同じファイル システム上で使用する必要があります。

4 proxy_cache_methods

構文: proxy_cache_methods [GET HEAD POST];
デフォルト値: proxy_cache_methods GET HEAD;
使用フィールド: http、server、location
GET/HEAD はステートメントを装飾するために使用されます。次のステートメントを使用して設定しただけでも GET /HEAD を無効にすることはできません:

proxy_cache_methods POST;

5 proxy_cache_min_uses

構文: proxy_cache_min_uses the_number;デフォルト: proxy_cache_min_uses 1;使用フィールド: http、サーバー、場所 クエリ後に応答がキャッシュされる回数、デフォルトは 1。

6 proxy_cache_valid

構文: proxy_cache_valid Reply_code [reply_code ...] time;
デフォルト値: None
使用フィールド: http、server、location
応答ごとに異なるキャッシュ時間を設定します。例: proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m;rreerreerree proxy_cache_valid 5m;

7 proxy_cache_use_stale

キャッシュの無効化 (複数のスレッドがローカル キャッシュを同時に更新する場合) を防ぐために、'updating' パラメーターを指定できます。これにより、1 つのスレッドのみがキャッシュを更新し、プロセス中に確実にキャッシュを更新します。このスレッドはキャッシュを更新しています。他のスレッドは、現在キャッシュにある期限切れのバージョンにのみ応答します。

コードを記述して構成を構成します:

各命令のフック (つまりコールバック) は ngx_http_proxy_module.c で定義されており、構成ファイルを読み取るときに呼び出されます。設定するときは、「HTTP_CACHE」を YES に設定するだけです (HTTP_CACHE 行は auto/options にあります)。 「proxy_cache_purge」ディレクティブでは、nginx をダウンロードする必要があります アドオンの「キャッシュパージ」モジュール。構成時に「--add-module=」を使用してコードをロードします。

次の添付ファイルには他の nginx キャッシュ コンテンツが含まれていますが、現在はほとんど使用されていません。興味がある場合は、詳細をご覧ください:

2. 従来のキャッシュ (404) の 1 つ この方法は、nginx の 404 エラーをバックエンドに送信し、proxy_store を使用してバックエンドから返されたページを保存します。 location / { root /home/html/;#ホームディレクトリは 1d で期限切れになります;#Web ページの有効期限 error_page 404 =200 /fetch$request_uri;#404 が指示しました/fetch ディレクトリへ 次へ } location /fetch/ {#404 Directed here Internal;#このディレクトリは外部から直接アクセスできないことを示します 1d 期限切れ;#有効期限Web ページ alias / home/html/;#仮想ディレクトリ ファイル システム アドレスは location/ と一致している必要があります。proxy_store はファイルをこのディレクトリに保存します proxy_pass http://xok.la/; #バックエンド アップストリーム アドレス、/fetch 同時にプロキシです proxy_set_header Accept-Encoding '';# バックエンドが圧縮 (gzip または deflate) コンテンツを返さないようにします。圧縮されたコンテンツを保存すると問題が発生します。 proxy_store on;#プロキシによって返されたファイルを保存するにはnginxを指定します proxy_temp_path /home/tmp;#一時ディレクトリ、このディレクトリは/home/htmlと同じハードディスクパーティションにある必要があります } 使用する場合、nginx には /home/tmp および /home/html にファイルを書き込む権限が必要であることに注意してください。Linux では、nginx は通常、nobody ユーザーとして実行されるように設定されているため、これら 2 つのディレクトリは chown する必要があります。もちろん、chmod 777 を使用することもできますが、経験豊富なシステム管理者は、777 を安易に使用しないことをお勧めします。3. 従来のキャッシュ 2 (!-e)原理は基本的に 404 ジャンプと同じですが、より簡潔に: location / { root /home/html/; proxy_store on; proxy_set_header Accept-Encoding ''; proxy_temp_path /home/tmp; if ( !-f $request_filename ) { proxy_pass http://xok. la/; } } この構成では、404 と比較して多くのコードが節約されていることがわかります。要求されたファイルがファイル システム上に存在するかどうかを判断するために !-f が使用されます。バックエンドに proxy_pass するだけで、戻り値も proxy_store に保存されます。 どちらの従来のキャッシュにも基本的に同じ長所と短所があります: 短所 1: nginx はファイル名のみを保存するため、read.php?id=1 などのパラメーターを含む動的リンクはサポートされていません。ユーザーが read.php?id=2 にアクセスしたときに誤った結果が返されるように、ファイル システムには read.php としてのみ保存してください。同時に、ホーム ページと http://xok.la/ の形式のセカンダリ ディレクトリ http はサポートされません。 //xok.la/download/、nginx は非常に正直で、リンクに従ってそのようなリクエストをファイル システムに書き込みます。このリンクは明らかにディレクトリであるため、保存は失敗します。このような場合、正しく保存するには書き直す必要があります。 欠点 2: nginx 内にはキャッシュの有効期限とクリーンアップのメカニズムがありません。これらのキャッシュされたファイルはマシンに永続的に保存され、キャッシュするものがたくさんあると、ハードディスクの容量全体がいっぱいになってしまいます。この目的のために、シェル スクリプトを使用して定期的にクリーンアップしたり、php などの動的プログラムを作成してリアルタイム更新を行うことができます。 欠点 3: キャッシュできるステータス コードは 200 個のみであるため、バックエンドから返される 301/302/404 などのステータス コードは、大量のアクセスを伴う疑似静的リンクが存在する場合にはキャッシュされません。削除しても貫通は継続し、後端にかなりの圧力がかかります。 欠点 4: nginx はストレージ メディアとしてメモリまたはハードディスクを自動的に選択しません。 もちろん、現在のオペレーティング システムにはオペレーティング システム レベルのファイル キャッシュ メカニズムが存在します。同時読み取りによって引き起こされるハードディスク上のファイル キャッシュについてあまり心配する必要はありません。 nginx 従来のキャッシュの欠点は、Squid などのキャッシュ ソフトウェアとは異なる特性でもあるため、利点とも言えます。本番アプリケーションでは、Squid のパートナーとして使用されることがよくあります。Squid は、? によるリンクをブロックできないことがよくありますが、nginx は、http://xok.la/? や http:/ などのアクセスをブロックできます。 /xok.la/ は Squid では 2 つのリンクとして扱われるため、2 回の侵入が発生します。一方、nginx では、リンクが http://xok.la/?1 または http になっても保存されます。 : //xok.la/?123、nginx によってキャッシュできないため、バックエンド ホストを効果的に保護します。 nginx は、リンクフォームをファイルシステムに非常に忠実に保存するため、リンクについては、キャッシュマシン上のキャッシュステータスとコンテンツを簡単に確認でき、他のファイルマネージャーと簡単に通信することもできます。 rsync などと組み合わせると、完全にファイル システム構造になります。 これら 2 つの従来のキャッシュはどちらも、Linux ではファイルを /dev/shm に保存できます。これは、メモリが使用されている場合に、期限切れのコンテンツを消去する速度を高めるためです。はるかに速くなります。 /dev/shm/ を使用する場合、tmp ディレクトリを /dev/shm パーティションに指定することに加えて、多数の小さなファイルやディレクトリがある場合は、メモリ パーティションも変更する必要があります。 i ノードの数と最大容量: mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm 上記のコマンドは 3G メモリを搭載したマシンで使用されます。 /dev/shm のデフォルトの最大メモリはシステム メモリの半分 (1500M) であるため、このコマンドはそれを 2500M に増やします。同時に、shm システム i ノードの数はデフォルトでは十分ではない可能性がありますが、興味深いことに注意してください。自由に調整できるということです。ここでは 480000 への調整は少し控えめですが、基本的には十分です。 4. memcached ベースのキャッシュ nginx は memcached をサポートしていますが、機能は特に強力ではなく、パフォーマンスは依然として非常に優れています。 location /mem/ { if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" ) { set $memcached_key "$1" ; memcached_pa​​ss 192.168.6.2:11211; } 有効期限は 70; }この設定は http://xok .la/mem/abc memcached キー abc を示しますデータを取得するために使用されます。 nginx には現在、memcached に書き込むためのメカニズムがないため、memcached へのデータの書き込みはバックエンドで動的言語を使用して行う必要があります。404 を使用してバックエンドにデータを書き込むことができます。 5. サードパーティのプラグイン ncache をベースにしています ncache は Sina Brothers によって開発された優れたプロジェクトであり、Squid キャッシュに似たいくつかの機能を実装しています。このプラグイン: http://code.google.com/p/ncache/

以上、内容の側面も含めて Nginx のキャッシュ構成について紹介しましたが、PHP チュートリアルに興味のある友人の参考になれば幸いです。