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

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 の他の関連記事に注目してください。

以下もご興味があるかもしれません:
  • nginx をアップグレードして HTTP2.0 をサポートする方法の例
  • 1 分で Nginx のバージョンをスムーズにアップグレードおよびロールバックする方法
  • Nginx バージョンのスムーズなアップグレードソリューションの詳細説明
  • nginx をアップグレードして http2 をサポートする方法
  • Nginx サービスのインストールとソフトウェアのアップグレード

<<:  MySQL データベースのステートメント ワイルドカード ファジー クエリの概要

>>:  js のマクロタスクとマイクロタスクについての簡単な説明

推薦する

背景画像にテキストを表示するためのCSS

効果: <div class="imgs"> <!-- 背景画...

Dockerはnginxをデプロイし、フォルダとファイル操作をマウントします

この間、私は docker を勉強していたのですが、nginx をデプロイするときに行き詰まりました...

Centos7.3は起動時に自動的に起動または指定されたコマンドを実行します

Centos7では、/etc/rc.d/rc.localファイルの権限が削減されており、実行権限があ...

JavaScriptのクローン作成についての簡単な説明

目次1. 浅いクローニング2. ディープクローニング1. 浅いクローニング浅いクローンでは配列やオブ...

HTML テーブルに複雑なテーブル ヘッダーを実装するためのサンプル コード

複雑な表を作成するには HTML を使用します。複雑なテーブルでは通常、td の rowspan 属...

Mysql のフィールドのデータの一部をバッチ置換する (推奨)

MYSQL のフィールドのデータの一部をバッチで置き換えます。具体的な導入は次のとおりです。 1....

MySQL ソートの原則とケース分析

序文ソートはデータベースの基本的な機能であり、MySQL も例外ではありません。ユーザーは、Orde...

データベースアカウントのパスワード暗号化の詳細な説明と例

データベースアカウントのパスワード暗号化の詳細な説明と例データベースアカウントとパスワードはデータベ...

MySQL5.7.27-winx64 バージョン win10 のダウンロードとインストールのチュートリアル図

MySQL 5.7 のインストール私たちは学校で MySQL データベースを学んでいます。先生は私た...

Vue で webSocket を使用してリアルタイムの天気を更新する方法

目次序文webSocket の操作と例について:ウェブソケット1. webSocketについて2. ...

Docker で Zookeeper をインストールする (スタンドアロンおよびクラスター)

Docker を起動したら、利用できるオプションを見てみましょう。 公式のものがある場合は、もちろ...

Linux Autofs 自動マウント サービスのインストールと展開のチュートリアル

目次1. autofs サービスの紹介2. Autofsのインストールと展開3. Autofs効果の...

MySQL Innodb インデックス メカニズムの詳細な紹介

1. インデックスとは何ですか?インデックスは、ストレージ エンジンがレコードをすばやく検索するため...

MYSQL 5.6 スレーブレプリケーションの展開と監視

MYSQL 5.6 スレーブレプリケーションの展開と監視MYSQL 5.6 のインストールと展開 #...

Linux で killall コマンドを使用してプロセスを終了する 8 つの例

Linux コマンドラインには、プロセスを強制終了するためのコマンドが多数用意されています。たとえば...