Nginx のパフォーマンスを向上させるための提案

Web アプリケーションが 1 台のマシンでのみ実行される場合、パフォーマンスを向上させるのは非常に簡単です。より高速なマシンに交換し、プロセッサ、メモリ、高速ディスクアレイを追加します。変更後、このマシンで実行されている WordPress サーバー、Node.js、または Java アプリケーションが高速化されます。 (アプリケーションが別のデータベースサーバーにもアクセスする場合も、これも簡単です。より高速な 2 台のマシンを見つけて、より高速なネットワークで接続します。)
問題は、マシンの速度が問題ではないことです。多くの場合、Web アプリケーションは、さまざまなタスクを切り替えたり、何千もの接続でユーザー要求を処理したり、ディスクへのファイルの読み取りと書き込みを行ったり、アプリケーションコードを実行したり、その他の処理を実行したりする必要があるため、遅くなります。そのため、アプリケーションサーバーでは、メモリ不足、ファイルのスワップ、ディスク I/O などのタスクを待機する要求が多数発生するなど、さまざまな状況が発生する可能性があります。ハードウェアをアップグレードするだけでなく、リバースプロキシサーバーを追加して上記のタスクの一部を共有するという、まったく異なるアプローチを選択することもできます。リバースプロキシサーバーは、アプリケーションを実行しているマシンの前に配置され、外部ネットワークからの要求を処理する役割を担います。リバースプロキシサーバーはインターネットに直接接続され、高速な内部ネットワークを使用してアプリケーションサーバーと通信します。リバースプロキシサーバーを使用すると、アプリケーションサーバーはページの構築に集中でき、ユーザーとアプリケーション間のやり取りを気にすることなく、ページを外部ネットワークのリバースプロキシに送信できます。アプリケーションサーバーはクライアントからの応答を待つ必要がないため、ほぼ最適な速度で実行できます。
リバースプロキシサーバーを追加すると、Web サーバーの柔軟性も向上します。たとえば、特定のタスクを実行しているサーバーが過負荷になった場合は、いつでも同じタイプの別のサーバーを追加できます。また、このサーバーがクラッシュした場合も簡単に交換できます。この柔軟性を考えると、リバースプロキシサーバーは、次のような他のパフォーマンス最適化手法の前提条件となることがよくあります。

負荷分散 (「提案 2」を参照): リバースプロキシサーバーで負荷分散サービスを実行して、トラフィックを複数のアプリケーションサーバーに均等に分散します。負荷分散を使用すると、アプリケーションサーバーを追加してもアプリケーションを変更する必要はまったくありません。
静的ファイルをキャッシュします (「推奨事項 3」を参照)。画像やコードなど、直接要求できるファイルは、リバースプロキシサーバーに保存して、クライアントに直接送信することができます。これにより、リクエストへの応答が速くなるだけでなく、アプリケーションサーバーの負荷が軽減され、実行速度も速くなります。
サイトのセキュリティを確保するには、リバースプロキシサーバーを構成してセキュリティレベルを向上させ、それを使用して攻撃を監視し、迅速に識別して対応することで、アプリケーションサーバーのセキュリティを維持できます。

NGINX はリバースプロキシサーバーとして使用するように特別に設計されているため、上記の最適化を自然にサポートします。 NGINX はイベント駆動型処理を採用しているため、従来のサーバーよりも効率的です。 NGINX Plus には、アプリケーションのヘルスチェック、固有のリクエストルーティング、高度なキャッシュ、アフターサポートなど、より高度なリバースプロキシ機能が追加されています。

提案2: 負荷分散サーバーを追加する

負荷分散サーバーの追加は比較的簡単ですが、サイトのパフォーマンスとセキュリティを大幅に向上させることができます。トラフィックを複数のサーバーに分散することで、Web サーバーをアップグレードする必要がなくなります。アプリケーション自体が適切に記述されていない場合や拡張が難しい場合でも、負荷分散によって他の変更を加えずにユーザーエクスペリエンスを向上させることができます。
負荷分散サーバーは、まずリバースプロキシサーバー (「提案 1」を参照) であり、インターネットからの要求を他のサーバーに転送する役割を担います。ここで重要なのは、負荷分散サーバーが 2 台以上のアプリケーションサーバーをサポートし、選択アルゴリズムを使用して異なるサーバー間で要求を分散できることです。最も単純な負荷分散アルゴリズムはラウンドロビンスケジューリングであり、新しい要求を次に利用可能なサーバーに順番に転送します。他のアルゴリズムは、アクティブな接続が最も少ないサーバーにリクエストを送信します。 NGINX Plus は、ユーザーセッションを同じサーバー上に保持するセッション永続性と呼ばれる機能をサポートしています。負荷分散サーバーは、他のサーバーがアイドル状態になっている間に 1 つのサーバーが過負荷になるのを防ぎ、パフォーマンスを大幅に向上させます。同時に、より安価なサーバーを選択しながら、サーバーを最大限に活用できるため、Web サーバーの容量を拡張することも容易になります。負荷分散によってスケジュールできるプロトコルには、HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcached、および TCP ベースのアプリケーションやその他の第 4 層プロトコルを含むその他のアプリケーション形式が含まれます。これを行うには、まず Web アプリケーションを分析してパフォーマンスの欠点がどこにあるかを確認し、どれを使用するかを決定する必要があります。負荷分散に使用される同じサーバーまたはサーバー群は、SSL 終了、クライアントに応じた HTTP/1/x または HTTP/2 のサポート、静的ファイルのキャッシュなどの他のタスクも実行できます。 NGINX は、負荷分散によく使用されます。詳細については、以前の紹介記事、構成記事、電子書籍、関連するオンラインビデオ、そしてもちろんドキュメントを参照してください。弊社の商用バージョンである NGINX Plus は、サーバーの応答時間に基づいた負荷のルーティングや、Microsoft NTLM プロトコルをサポートする負荷分散など、より多くの負荷分散機能をサポートしています。

ヒント3: 静的コンテンツと動的コンテンツをキャッシュする

キャッシュを使用すると、コンテンツをクライアントに高速配信できるため、Web アプリケーションのパフォーマンスが向上します。キャッシュ戦略には、コンテンツの前処理、より高速なデバイスへのコンテンツの保存、コンテンツをクライアントの近くに保持すること、およびこれらの戦略の組み合わせが含まれます。キャッシュには2つの種類があります。

静的コンテンツのキャッシュ: 画像 (JPEG、PNG) やコード (CSS、JavaScript) などの頻繁に変更されないファイルは、エッジサーバーに保存して、コンテンツまたはディスクからすばやく取得できます。
動的コンテンツのキャッシュ。多くの Web アプリケーションは、ページ要求ごとに新しい HTML を生成します。生成された各 HTML を短期間キャッシュすると、配信されるコンテンツが十分に新しいことを保証しながら、生成する必要があるページの総数を大幅に削減できます。

ページが 1 秒間に 10 回表示され、そのページを 1 秒間キャッシュすると仮定すると、このページのリクエストの 90% はキャッシュから取得されます。静的コンテンツを個別にキャッシュすると、新しく生成されたページであっても、ほとんどがキャッシュされたコンテンツから提供される可能性が高くなります。 Web アプリケーションによって生成されたコンテンツをキャッシュするための主な手法は 3 つあります。

コンテンツをユーザーの近くに配置します。ユーザーに近いため、送信時間が短くなります。
コンテンツをより高速なマシンに配置します。機械が速くて検索速度も速いです。
過度に使用されているマシンからコンテンツを削除します。場合によっては、タスクが多すぎるために、特定のタスクに集中しているときよりもマシンの動作がはるかに遅くなることがあります。このとき、コンテンツを他のマシンに移動することは、キャッシュされたコンテンツだけでなく、キャッシュされていないコンテンツにとっても有益です。これは、コンテンツをホストしているホストの負担が軽減されるためです。

Web アプリケーションキャッシュは、Web アプリケーションサーバーの内部または外部に実装できます。まず、アプリケーションサーバーの負荷を軽減するために、動的コンテンツをキャッシュすることを検討してください。 2 番目に、キャッシュは静的コンテンツ (動的に生成されたコンテンツの一時コピーを含む) に使用されるため、アプリケーションサーバーの負荷がさらに軽減されます。次に、アプリケーションサーバーの負荷を軽減し、転送時間を短縮するために、キャッシュをより高速なマシンまたはユーザーに近いマシンに移動することを検討します。キャッシュを適切に使用すると、アプリケーションの応答速度が大幅に向上します。多くの Web ページでは、大きな画像などの静的データがコンテンツの半分以上を占めることがよくあります。キャッシュがない場合、この種のデータのクエリと転送には数秒かかる可能性がありますが、キャッシュを使用すると、ほんの一瞬で済む可能性があります。キャッシュの使用方法を説明すると、NGINX と NGINX Plus は、キャッシュの場所とサイズ、最大キャッシュ時間、およびその他のパラメータを指定する proxy_cache_path と proxy_cache という 2 つのディレクティブを使用してキャッシュを設定します。 3 番目 (かつ人気がある) のディレクティブ proxy_cache_use_stale を使用すると、新しいコンテンツを提供するはずだったサーバーが混雑していたりダウンしていたりする場合でも、キャッシュに古いファイルを提供するように指示できます。クライアントにとっては、コンテンツを取得することは、まったく取得しないよりも常に優れています。ユーザーの視点から見ると、これにより、サイトまたはアプリケーションが非常に安定しているというイメージを確立することもできます。 NGINX Plus は、キャッシュの消去や、リアルタイム監視のためにキャッシュの状態を視覚化するダッシュボードなど、高度なキャッシュ機能をサポートしています。 NGINX のキャッシュの詳細については、リファレンスドキュメントの「NGINX コンテンツキャッシュ」および NGINX Plus 管理者ガイドを参照してください。注: キャッシュには、開発、意思決定、運用が関係します。この記事で説明したような完全なキャッシュ戦略は、DevOps の観点から検討する価値を反映しています。つまり、開発者、設計者、運用および保守担当者が協力して、Web サイトの機能、応答時間、セキュリティ、ビジネス目標を確保します。

ヒント4: データを圧縮する

圧縮によりパフォーマンスも大幅に向上します。画像、ビデオ、音楽、その他のファイル (JPEG および PNG、MPEG-4、MP3) には非常に成熟した効率的な圧縮標準があり、そのいずれもファイルサイズを 1 桁以上削減できます。
HTML (プレーンテキストと HTML タグ)、CSS、JavaScript コードなどのテキストファイルは、多くの場合、圧縮されずに転送されます。このデータを圧縮すると、特に接続速度が遅く信頼性の低いモバイルユーザーにとって、Web アプリケーションの体感パフォーマンスが大幅に向上することがあります。テキストデータはページインタラクションにおいて必要な補助的な役割を果たすことができますが、マルチメディアデータはあくまでも添え物のようなものです。スマートコンテンツ圧縮により、HTML、JavaScript、CSS などのテキストコンテンツのサイズを 30% 以上削減できるため、読み込み時間も短縮されます。
SSL を使用する場合、圧縮によって SSL エンコードする必要があるデータの量が削減され、そのデータの圧縮に費やされる CPU 時間を補うことができます。
データを圧縮する方法はたくさんあります。たとえば、勧告 6 の HTTP/2 に関する部分では、ヘッダーデータの圧縮に特に適した新しい圧縮のアイデアについて説明しています。テキスト圧縮の別の例として、NGINX で GZIP 圧縮を有効にすることができます。テキストデータを事前に圧縮した後、gzip_static ディレクティブを使用して .gz ファイルを直接送信できます。

ヒント5: SSL/TLSを最適化する

ますます多くの Web サイトが、Secure Sockets Layer (SSL) プロトコル、さらには Transport Layer Security (TLS) プロトコルを使用しています。 SSL/TLS は、オリジンサーバーからユーザーに送信されるデータを暗号化することで、Web サイトのセキュリティを向上させます。 Google は、SSL/TLS を使用するサイトの検索エンジンランキングを上げることで、このプロセスを大幅に促進します。
採用が増えているにもかかわらず、SSL/TLS によって生じるパフォーマンスの低下も多くの Web サイトで問題となっています。 SSL/TLS によって Web サイトの速度が低下する理由は 2 つあります。 1. それぞれの新しい接続を開く最初のハンドシェイクでは暗号化キーを作成する必要があり、ブラウザが HTTP/1.x を使用して各サーバーに複数の接続を確立する方法によってこの問題はさらに悪化します。サーバー側でデータを暗号化し、クライアント側でデータを復号化する操作もオーバーヘッドになります。 SSL/TLS の使用を促進するために、HTTP/2 と SPDY (推奨事項 6 を参照) の作成者は、ブラウザーがセッションごとに 1 つの接続のみを確立できるようにこれら 2 つのプロトコルを設計しました。これにより、SSL によってパフォーマンスが低下する 2 つの主な理由のうちの 1 つが解消されます。ただし、SSL/TLS パフォーマンスの最適化に関しては、まだできることがたくさんあります。 SSL/TLS を最適化する方法は、Web サーバーごとに異なります。 NGINX を例に挙げてみましょう。NGINX は OpenSSL を使用し、通常のマシンで実行できるため、カスタマイズされたマシンに近いパフォーマンスを提供できます。 NGINX SSL パフォーマンスでは、SSL/TLS 暗号化と復号化のオーバーヘッドを最小限に抑える方法について詳しく説明します。さらに、SSL/TLS のパフォーマンスを向上させるさまざまな方法を紹介する記事がこちらにあります。簡単にまとめると、関係する主な技術は次のとおりです。

セッションキャッシュ。 ssl_session_cache ディレクティブを使用してキャッシュを有効にし、各 SSL/STL 接続に使用されるパラメータをキャッシュします。
セッションチケットまたは ID。特定の SSL/TLS セッションに関する情報をセッションチケットまたは ID として保存し、再度ハンドシェイクすることなく接続を再利用できるようにします。
OCSP エンベロープ。 SSL/TLS 証明書情報をキャッシュすることでハンドシェイク時間を短縮します。

NGINX と NGINX Plus はどちらも SSL/TLS を終了できます。つまり、他のサーバーとのクリアテキスト通信を維持しながら、クライアント側の情報の暗号化と復号化を処理できます。 SSL/TLS 終了を処理するように NGINX または NGINX Plus を設定するには、いくつかの手順を実行する必要があります。 TCP 接続を受け入れるサーバーで NGINX Plus を使用する場合は、ここにあるセットアップ手順に従ってください。

推奨事項6: HTTP/2またはSPDYを実装する

すでに SSL/TLS を使用しているサイトでは、接続に必要なハンドシェイクが 1 回だけなので、HTTP/2 または SPDY を使用するとパフォーマンスが向上する可能性があります。 SSL/TLS、HTTP/2、SPDY を使用していないサイトでは、SSL/TLS に切り替えると応答性が低下する可能性があります (通常はパフォーマンスが低下します)。
Google は、HTTP/1.x の高速化を実現することに専念する SPDY プロジェクトを 2012 年に開始しました。 HTTP/2 は、IETF によって最近承認された SPDY に基づく標準です。 SPDY は広くサポートされていますが、まもなく HTTP/2 に置き換えられます。
SPDY と HTTP/2 の鍵は、複数の接続ではなく 1 つの接続のみを使用することです。この単一の接続は多重化されているため、複数の要求と応答を同時に伝送できます。
1 つの接続のみを維持することで、複数の接続のセットアップと管理のオーバーヘッドが削減されます。また、接続は SSL にとって特に重要です。SSL/TLS が安全な接続を確立するために必要なハンドシェイク時間を最小限に抑えることができるためです。
SPDY プロトコルでは SSL/TLS の使用が必要ですが、これは HTTP/2 では正式には必須ではありませんが、現在 HTTP/2 をサポートしているすべてのブラウザは SSL/TLS が有効になっている場合にのみ HTTP/2 を使用します。つまり、HTTP/2 をサポートするブラウザは、Web サイトが SSL を使用し、サーバーが HTTP/2 トラフィックを受け入れる場合にのみ HTTP/2 を使用します。それ以外の場合、ブラウザは HTTP/1.x に基づいて通信します。
SPDY または HTTP/2 を実装すると、ドメイン名のシャーディング、リソースのマージ、イメージスプライトなどの HTTP の以前のパフォーマンス最適化対策は不要になります。したがって、コードとデプロイメントも簡素化できます。 HTTP/2 がもたらす変更の詳細については、ホワイトペーパーを参照してください。

NGINXは長い間SPDYをサポートしており、現在SPDYを使用しているほとんどのサイトはNGINを実行しています。
X. NGINX は HTTP/2 をサポートした最初の企業でもあります。2015 年 9 月、NGINX Open Source と NGINX Plus が HTTP/2 のサポートを開始しました。
NGINX では、時間の経過とともに、ほとんどのサイトが SSL を有効にし、HTTP/2 に移行すると予想しています。これにより、Web サイトのセキュリティが強化されるだけでなく、新しい最適化手法の登場により、よりシンプルなコードでより高いパフォーマンスを実現できます。

推奨事項7: ソフトウェアのアップグレード

アプリケーションのパフォーマンスを向上させる簡単な方法は、信頼性とパフォーマンスに基づいてソフトウェアを選択することです。さらに、高品質なコンポーネントの開発者は継続的にパフォーマンスを改善し、問題を修正する可能性が高いため、最新の安定したバージョンを使用するとコスト効率が高くなります。新しいリリースは開発者やユーザーからより多くの注目を集め、新しいハードウェアのチューニングを含む新しいコンパイラ最適化手法も活用します。旧バージョンと比較すると、新しくリリースされた安定バージョンは明らかにパフォーマンスが向上しています。アップグレードを継続することで、チューニング、問題の修正、セキュリティ警告についても最新の状態に保つことができます。ソフトウェアをアップグレードしないと、新しい機能を活用できなくなる可能性もあります。たとえば、HTTP/2 には現在 OpenSSL 1.0.1 が必要です。 2016 年後半から、HTTP/2 では 2015 年 1 月にリリースされた OpenSSL 1.0.2 が必要になります。 NGINX ユーザーは、ソケット共有、スレッドプール (以下を参照)、継続的なパフォーマンス最適化をサポートする最新バージョンの NGINX オープンソースソフトウェアまたは NGINX Plus から始めることができます。したがって、ソフトウェアをチェックして、最新バージョンに更新してください。

ヒント8: Linuxを調整する

Linux は、今日のほとんどの Web サーバーの基盤となるオペレーティングシステムです。すべてのインフラストラクチャの基盤として、Linux はパフォーマンスの向上に不可欠です。デフォルトでは、多くの Linux システムは比較的保守的であり、デスクトップオフィスの要件が唯一の要件であり、少量のリソースがチューニングの目標となっています。 Web アプリケーションの場合、最適なパフォーマンスを実現するには再チューニングが必ず必要です。 Linux の最適化は Web サーバーごとに異なります。 NGINX を例にとると、次の点を考慮することができます。
在庫キュー。一部の接続が処理されていないことが判明した場合は、NGINX によって処理されるのを待機している接続の最大数である net.core.somaxconn を増やすことができます。接続制限が低すぎる場合はエラーメッセージが表示されるので、エラーメッセージが表示されなくなるまでこの値を徐々に増やすことができます。

ファイル記述子。 NGINX は接続ごとに最大 2 つのファイル記述子を使用します。システムが多数の接続を処理する場合、増加した負荷をサポートするために、システム全体の記述子の制限 sys.fs.file_max とユーザーファイル記述子の制限 nofile を増やす必要がある場合があります。
一時的なポート。プロキシとして使用する場合、NGINX は各アップストリームサーバーに一時ポートを作成します。 net.ipv4.ip_local_port_range を設定すると、ポート値の範囲を広げて、使用可能なポートの数を増やすことができます。さらに、非アクティブなポートが再利用のために解放されるまでの待機時間を制御する net.ipv4.tcp_fin_timeout の値を減らして、ターンオーバーを高速化することもできます。
NGINX の場合、Linux システムを簡単に最適化してスループットを向上させる方法については、NGINX パフォーマンスチューニングガイドを参照してください。

ヒント9: Webサーバーを調整する

どの Web サーバーを使用する場合でも、アプリケーションに合わせて調整する必要があります。以下の提案はどの Web サーバーにも適用されますが、セットアップ手順は NGINX のみに適用されます。

アクセスログ。すべてのリクエストログをすぐにディスクに書き込まないでください。メモリにキャッシュしてから、バッチ処理することができます。 NGINX の場合、access_log ディレクティブに buffer=_size_ パラメータを追加して、メモリバッファがいっぱいになるまで待ってからログをディスクに書き込みます。 **flush=_time_** パラメータを追加すると、バッファの内容も指定された時間にディスクに書き込まれます。
バッファ。バッファリングは、バッファがいっぱいになるまで部分的な応答をメモリに保存するために使用され、クライアントへの応答をより効率的に行うことができます。メモリに収まらない応答はディスクに書き込まれ、パフォーマンスが低下します。 NGINX バッファリングが有効になっている場合は、proxy_buffer_size および proxy_buffers ディレクティブを使用して管理できます。
クライアントのアクティブな接続。アクティブな接続により、特に SSL/TLS を使用する場合にレイテンシを削減できます。 NGINX の場合、クライアントの keepalive_requests の値を増やすことができます。この値はデフォルトで 100 に設定されています。また、keepalive_timeout の値を増やしてアクティブな接続を長く維持し、後続のリクエストに迅速に応答できるようにすることもできます。
アップストリームのアクティブ接続。上流接続、つまりアプリケーションサーバーやデータベースサーバーへの接続も、アクティブ接続の設定によってメリットを得ることができます。アップストリーム接続の場合、アクティブ接続（各ワーカープロセスで使用できるアイドル状態のアクティブ接続の数）を増やすことができます。これにより、接続の再利用が改善され、接続の再開が減ります。アクティブ接続の詳細については、このブログ投稿を参照してください。
制限。クライアントが使用するリソースを制限すると、パフォーマンスとセキュリティが向上します。 NGINX の場合、limit_conn および limit_conn_zone ディレクティブは指定されたソースからの接続数を制限し、limit_rate は帯域幅を制限します。これらの設定により、正当なユーザーがリソースを「盗む」ことを防ぎ、攻撃を防ぐのにも役立ちます。 limit_req および limit_req_zone ディレクティブは、クライアント要求を制限します。アップストリームサーバーへの接続の場合、アップストリーム設定領域の server ディレクティブで max_conns パラメーターを使用して、アップストリームサーバーへの接続数を制限し、過負荷を防ぐことができます。関連するキューディレクティブは、max_conns 制限に達した後、指定された数のリクエストを指定された時間保持するキューを作成します。
作業プロセス。ワーカープロセスはリクエストの処理を担当します。 NGINX は、イベントベースのモデルと OS に依存するメカニズムを使用して、ワーカープロセス間でリクエストを効率的に分散します。 worker_processes の値を CPU ごとに 1 つのワーカープロセスに設定することをお勧めします。ほとんどのシステムでは、必要に応じて、worker_connections の値 (デフォルトは 512) を上げることができます。システムに最適な値を見つけるために実験してください。
ソケットシャーディング。通常、ソケットリスナーは新しい接続をすべてのワーカープロセスに配布します。ソケットシャーディングは、各ワーカープロセスに対してソケットリスナーを作成し、カーネルはソケットリスナーが利用可能な場合にその接続を割り当てます。これにより、ロックの競合が軽減され、マルチコアシステムのパフォーマンスが向上します。ソケットシャーディングを有効にするには、listen ディレクティブに reuseport パラメータを含めます。
スレッドプール。時間のかかる操作により、コンピュータのプロセスがブロックされる可能性があります。 Web サーバーソフトウェアの場合、ディスクアクセスによって、メモリ内計算やレプリケーションなどの多くの高速操作が妨げられる可能性があります。スレッドプールを使用すると、メイン処理ループは高速な操作を継続的に実行しながら、低速な操作は別のタスクセットに割り当てられます。ディスク操作が完了すると、結果がメイン処理ループに返されます。 NGINX では、read() システムコールと sendfile() はスレッドプールにオフロードされます。

ヒント: オペレーティングシステムまたは周辺機器の設定を変更する場合は、一度に 1 つの項目のみを変更して、パフォーマンスをテストしてください。変更によって問題が発生したり、パフォーマンスが改善されない場合は、変更を元に戻してください。

ヒント10: リアルタイムの動向を監視して問題やボトルネックを特定する

高いアプリケーションパフォーマンスを維持するための鍵は、アプリケーションパフォーマンスをリアルタイムで監視することです。特定のデバイスと対応する Web インフラストラクチャ内のアプリケーションの動態をリアルタイムで監視する必要があります。
サイトのアクティビティの監視は主に受動的です。つまり、何が起こっているかはわかりますが、問題を見つけて修正するのはユーザーの責任です。
監視により、次の問題を把握できます。1. サーバーのダウンタイム 2. サーバーの不安定性、接続の失敗 3. サーバー上の大規模なキャッシュ障害 4. サーバーから送信された誤ったコンテンツ
New Relic や Dynatrace などのグローバルパフォーマンス監視ツールは、リモートページの読み込みにかかる時間を監視するのに役立ちます。一方、NGINX は、アプリケーションの配信終了を監視するのに役立ちます。アプリのパフォーマンスデータを見れば、最適化がユーザーにとって本当に効果的かどうか、また増加するトラフィックに対応するためにスケールアップが必要な時期がわかります。
ユーザーが問題をできるだけ早く検出できるように、NGINX Plus には、頻繁に発生する問題を報告するアプリケーションヘルスチェック機能が追加されました。 NGINX Plus には、既存のタスクが完了するまで新しい接続をブロックするセッションドレイン機能と、回復したサーバーが負荷分散されたクラスター内で速度を上げるためのスロースタート機能もあります。ヘルスチェックを適切に使用すると、問題がユーザーエクスペリエンスに大きな影響を与える前に問題を特定するのに役立ちます。また、セッションドレインとスロースタートを使用すると、認識されるパフォーマンスや稼働時間に影響を与えることなくサーバーを置き換えることができます。この画像は、サーバー、TCP 接続、キャッシュをカバーする、NGINX Plus に組み込まれたリアルタイムアクティビティ監視のダッシュボードを示しています。

結論: パフォーマンスが10倍向上

パフォーマンスの向上は、Web アプリケーションごとに大きく異なります。実際の改善は、予算、時間、既存の実装と理想的なパフォーマンスのギャップによって異なります。では、アプリケーションのパフォーマンスを 10 倍向上させるにはどうすればよいでしょうか?それぞれの最適化提案の可能性を理解していただくために、これまでの提案の実装ガイドラインをいくつかご紹介します。皆様が必要なものを取り入れていただければ幸いです。

リバースプロキシサーバーと負荷分散。負荷分散を行わない場合、またはプールされた負荷分散を行うと、パフォーマンスが非常に低下する可能性があります。 NGINX などのリバースプロキシサーバーを追加すると、Web アプリケーションがメモリとディスク間で行うラウンドトリップの回数を減らすことができます。負荷分散により、過負荷のサーバーからアイドル状態のサーバーにタスクを転送でき、拡張も容易になります。これらの変更により、パフォーマンスが大幅に向上します。元の展開方法の最悪のケースと比較すると、10 倍のパフォーマンス向上は非常に簡単なことです。10 倍未満であっても、全体的には質的な飛躍です。
動的コンテンツと静的コンテンツをキャッシュします。 Web サーバーがアプリケーションサーバーとしても機能する場合は、動的コンテンツをキャッシュすることで、ピーク時にパフォーマンスを 10 倍向上できます。静的コンテンツをキャッシュすると、パフォーマンスが数倍向上することもあります。
データを圧縮します。 JPEG、PNG、MPEG-4、MP3 などの圧縮形式を使用すると、パフォーマンスが大幅に向上します。これらすべての対策を講じると、圧縮されたテキストデータ (コードと HTML) によって、初期ページの読み込み時間が 2 倍短縮されます。
SSL/TLS を最適化します。セキュリティハンドシェイクはパフォーマンスに大きな影響を与えるため、これを最適化することで、特にテキストを多用するサイトでは初期応答が最大 2 倍速くなります。メディアファイルを SSL/TLS 用に最適化しても、パフォーマンスはわずかに向上します。
HTTP/2 と SPDY を実装します。 SSL/TLS を使用する場合、これら 2 つのプロトコルにより、Web サイトの全体的なパフォーマンスが向上する可能性があります。
Linux および Web サーバーのチューニング。最適化されたバッファリング戦略を使用し、アクティブな接続を使用し、時間のかかるタスクを独立したスレッドプールにオフロードすると、パフォーマンスが大幅に向上します。たとえば、スレッドプールを使用すると、ディスクを集中的に使用するタスクのパフォーマンスを少なくとも 1 桁向上させることができます。

上記は、Nginx のパフォーマンスを改善するためのいくつかの提案の詳細です。Nginx のパフォーマンス改善の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。

以下もご興味があるかもしれません: