主題
- #nginx設定
nginxはオープンソースで、ウェブサーバーまたはウェブプロキシサーバーとして広く利用されています。
適切に設定すれば、静的コンテンツを効率的に配信できます。
その中でも、いくつかの主要な設定を記録したいと思います。
パフォーマンスに関するいくつかの主要な設定
1. gzip圧縮
ウェブサイトを読み込む際、ウェブサーバーからJavaScript、画像、HTML、CSSなど、無数のファイルを受け取ります。
この時、これらのコンテンツをそのまま配信するのではなく、gzip圧縮を利用することで、転送されるデータ量を大幅に削減できます。
つまり、これを実装することで
- データ量が減り、帯域幅を節約できます。
- サーバーリソースを節約できます。
- ユーザーにとって、実際の読み込み速度が向上します。
一方で、サーバーはコンテンツに応答する前にgzip圧縮を実行する必要があるため、サーバーのCPU使用率が高くなる可能性があります。
どの種類のファイルを圧縮するか、圧縮率はどの程度にするか、どのくらいの大きさのファイルを圧縮するかなど、運用レベルに適用する前にテストが必要です。
以下は、gzipに関するいくつかの設定です。
* gzip_varyは、クライアントがgzipをサポートする場合とサポートしない場合に、コンテンツを圧縮版と非圧縮版でそれぞれ送信できるように指示します。（クライアントのリクエストヘッダー（Accept-Encoding）に応じて、異なるバージョンのコンテンツが提供される可能性があることを示します。）
2. proxy_buffer設定
nginxはクライアントにレスポンスを送信する前に、レスポンスをバッファーに保存します。
ウェブサーバーがクライアントにレスポンスを送信する際、クライアントの速度が遅い場合、サーバーはデータの送信を待ち続ける必要があります。（ネットワークボトルネック）
この時、サーバーリソースを継続的に使用しているため、これを解決するためにバッファーを使用して、クライアントの処理速度に関係なくレスポンスを一時的に処理します。これにより、以下の利点があります。
- サーバー負荷の最適化
- ネットワークボトルネックの軽減
※ バッファーサイズを大きくしすぎると、テキストストリーミングなどのリアルタイムデータ転送が遅延する可能性があるため、必ずテストが必要です。特に近年AI関連サービスが多く登場していますが、テキストストリームが機能しない場合は、この設定を必ず確認しましょう。
3. workerとhttpの設定
workerはクライアントのリクエストを処理するプロセスであり、サーバーのCPUコアごとにいくつ持つかを設定できます。
httpは一般的にリクエスト-接続-レスポンス-接続終了ですが、複数回のリクエストに対して接続するリソースを削減するために、クライアント接続を維持できます。これがkeep alive設定です。
上記2つをまとめる理由は以下の通りです。
使用しているサーバーのコア数が4つの場合、理論上可能な接続数は1,024 * 4 = 4,096です。
(リソースやトラフィック環境によって正確ではない場合があります)
4,096個のクライアントが同時接続し、65秒間すべてのkeepaliveを占有している場合、
4,097番目のユーザーが接続しようとすると、接続できなくなるため、レスポンスが遅延する可能性があります。
したがって、auto scalingなどによってサーバーリソースが安定していると仮定した場合、イベント時にレスポンス遅延が発生する場合は、上記の設定が間接的に影響を与える可能性があります。
4. その他 - locationブロック
proxy bufferなどの設定の一部は、リクエストURLごとに適用できます。
* keep-aliveなどの設定の一部はHTTP/Serverレベルで適用されるため、ブロックごとに設定できません。
server {
listen 80;
server_name example.com;
上記の設定により、ウェブパフォーマンスを最適化できます。様々なテストケースを考慮して十分にテストを行い、サーバーパフォーマンスを最適化しましょう！
* サーバーのダウンタイムなしに変更された設定のnginxを適用できるため、非常に安定しています。
コメント0