こんにちは 最近、ngx_http_gzip_static_moduleモジュールに興味があり、ホームサーバーを少しずつ異なるnginx圧縮設定で駆動して、最新のプロセッサが本当に高速で、圧縮を9ビットに設定できるようにしました。 lenta.ruのマージされたメインページである170kbは、実験ファイルとして機能しました。 テスト中に、nginxプロセスの数の選択に関する私の見解を変えた興味深い機能が発見されました。
鉄とソフトウェア
テストは、Ubuntu Server 10.04、nginx 0.8.45、プロセッサ-Opteron 165（2コア、1メートルキャッシュ、1.8Ghz）で実行されました。
テストはサーバー自体で実行されました。 ギガビットネットワークを介して別のコンピューターからそれらを繰り返しました-結果は同じで、違いはネットワーク帯域幅に依存している場合のみです。
Banal gzipオン;
私はnginxでgzipをオンにしてテストを実行し、驚くべき機能を偶然見つけました：パフォーマンスが圧縮速度に依存する場合、2プロセスのnginxは1プロセスのほぼ2倍速く動作し、スレッドで圧縮されません...
ご覧のとおり、パフォーマンスはプロセッサのパフォーマンスによって非常に制限されており、「プロセッサは現在高速です」と考える理由はありません。9ビットの圧縮を冷静に行ってもうまくいきません。 9ビットに圧縮する場合、nginxはプロセッサのすべてのコアのみを消費し、4mb /秒の圧縮コンテンツのみを圧縮し、ギガビットは言うまでもなく100mbitのチャネルをロードすることさえできません。
圧縮レベルの選択について
圧縮ファイルのサイズのグラフ（または下の表）を見ると、5-pの後、圧縮は実質的に増加しないことがわかりますが、9倍圧縮すると速度はほぼ2倍低下します。
| 圧縮比 | 1秒あたりのリクエスト | 圧縮サイズ（元の170kb） |
| 1 | 370 | 51.7 |
| 2 | 350 | 48.9 |
| 3 | 294 | 45.7 |
| 4 | 242 | 44,2 |
| 5 | 181 | 41.3 |
| 6 | 134 | 39.7 |
| 7 | 115 | 39.5 |
| 8 | 103 | 39,4 |
| 9 | 102 | 39,4 |
したがって、私見では、圧縮を5より上に置くことは価値がありません。
黄金の弾丸：ngx_http_gzip_static_module
このモジュールを使用すると、同じファイルを何度も圧縮する必要がなくなります。 できるだけ事前に圧縮し、拡張子が.gzの同じディレクトリに配置するだけです。圧縮されている場合は、圧縮ファイルがすぐに返されます。
ご覧のとおり、天と地。 .gzファイルの存在の追加チェックにより、.gzファイルがない場合はパフォーマンスがわずかに低下することにも注意してください。
ボーナストラック：たとえば、圧縮レベルが1のgzip_staticと通常のgzipの両方を有効にすると、以前に圧縮されたファイルが見つかった場合はそのファイルが返され、そのようなファイルがない場合、またはApacheのコンテンツが来た場合は、1で圧縮されますできるだけ早く。
唯一の問題は、事前に圧縮されたファイルを最新の状態に保つことです。ここでは、クラウンまたは展開スクリプトによって、誰にとっても便利です。 もちろん、nginxによってファイルが自動的に生成、保存、更新されると、さらに便利になります...ああ、夢、夢...
まとめ
- nginxでは、すべてを9で圧縮することはできません。トラフィックが大きい場合、多くのプロセッサを消費します。 5を超えると、圧縮を適用してもあまり意味がありません。 サイズは実際には減少せず、速度は大幅に低下します。
- gzipを使用する場合のnginxプロセスの数は、プロセッサコアの数以上である必要があります。
1では十分ではありません。 gzip圧縮は、1つのコアでのみ発生します。 - gzip_static-非常に便利で、圧縮された静的変数を返す際に大きな利点があります