Webアプリケーションのパフォーマンスに言及することはかつてないほど緊急になっています。
オンライン経済活動の割合は日々増加しており、発展途上国や地域の経済活動の5％以上がオンラインで行われています（関連データについては、この記事の最後にあるリソースを参照してください）。ハイパーリンクとオンラインがいつでも存在するこの現代の世界では、ユーザーの期待は以前とはかけ離れています。Webサイトがすぐに応答できない場合、アプリケーションはすぐに実行できず、ユーザーは向きを変えて競合他社に向きを変えます。
約10年前のAmazonの調査によると、ページの読み込み時間を1/10秒短縮すると、収益が1％増加する可能性があります。別の最近の調査でも、インタビューを受けたサイト所有者の半数以上が、アプリケーションのパフォーマンスの低下が収益の減少またはユーザーの損失につながっていると述べていることが示されました。
ウェブサイトはどれくらい速いですか？ページの読み込みにかかる秒ごとに、ユーザーの約4％が離れます。トップランクのeコマースサイトの最初のインタラクション時間は1〜3秒で、この間隔でのコンバージョン率が最も高くなります。明らかに、Webアプリケーションのパフォーマンスの重要性は日々高まっています。
パフォーマンスの向上は実際には難しくありませんが、結果を確認する方法は困難です。この記事では、参考までにWebサイトのパフォーマンスを約10倍向上させることができる10の提案を示します。さまざまなパフォーマンス最適化手法を包括的にカバーするのは初めてですが、これらの提案にはNGINXからのサポートが少し必要になる場合があります。これらの推奨事項には、パフォーマンスに加えて、セキュリティの向上も含まれます。
1 推奨事項1：リバースプロキシサーバーを使用して、アプリケーションをより高速かつ安全にします
Webアプリケーションは、単一のマシン上で実行する場合は、その性能を向上させる必要があり、非常に簡単です：、いくつかのプロセッサでよりいくつかの給料より多くのメモリをより速く置き換え、および、ディスクアレイは、高速を持っています。変更後、このマシンで実行されているWordPressサーバー、Node.js、またはJavaアプリケーションが高速化されます。（アプリケーションが別のデータベースサーバーにアクセスする場合も簡単です。2台のより高速なマシンを見つけて、より高速なネットワークに接続します）
問題は、マシンの速度が問題ではないということです。多くの場合、Webアプリケーションはさまざまなタスクを切り替える必要があるため、低速です。しばらくすると、接続時に何千ものユーザーリクエストを処理し、ファイルの読み取りとディスクへの書き込みを行ってから、実行する必要があります。アプリケーションコード、そして彼らはそれを再びしなければなりません。何か他のもの。その結果、アプリケーションサーバーには、メモリ不足、ファイルのスワップ、またはハードディスクI / Oなどのタスクを待機する多くの要求が発生するなどのさまざまな条件が発生する可能性があります。
ハードウェアのアップグレードに加えて、実際には別のまったく異なる方法を選択できます。リバースプロキシサーバーを追加して、上記のタスクの一部を共有します。リバースプロキシサーバーは、アプリケーションを実行しているマシンの前にあり、外部ネットワークからの要求を処理します。リバースプロキシサーバーはインターネットに直接接続されており、高速の内部ネットワークを使用してアプリケーションサーバーと通信します。
リバースプロキシサーバーを使用すると、アプリケーションサーバーはページの作成に集中でき、ユーザーとアプリケーション間の相互作用を気にすることなく、ページをリバースプロキシに渡してインターネットに送信できます。クライアントの応答を待つ必要がないため、アプリケーションサーバーの動作速度はほぼ最適なレベルに達する可能性があります。
リバースプロキシサーバーを追加すると、Webサーバーに柔軟性を追加することもできます。たとえば、特定のタスクを実行しているサーバーが過負荷になった場合、同じタイプの別のサーバーをいつでも追加できます。このサーバーがダウンした場合、簡単に交換できます。
この柔軟性を考慮すると、リバースプロキシサーバーは、次のような他のパフォーマンス最適化方法の前提条件となることがよくあります。
-
負荷分散（「推奨事項2」を参照）。リバースプロキシサーバーは負荷分散サービスを実行し、トラフィックは複数のアプリケーションサーバーに均等に分散されます。負荷分散を使用すると、アプリケーションサーバーを追加しても、アプリケーションを変更する必要はまったくありません。
-
キャッシュ静的ファイル（「推奨事項3」を参照）。画像やコードなど、直接要求できるファイルは、クライアントに直接配信するためにリバースプロキシサーバーに保存できます。これにより、リクエストへの応答が速くなるだけでなく、アプリケーションサーバーの負担が軽減され、操作が高速化されます。
-
サイトのセキュリティを確保するために、リバースプロキシサーバーを構成してセキュリティレベルを向上させ、それを使用して監視し、攻撃をすばやく特定して対応することで、アプリケーションサーバーのセキュリティを維持できます。
NGINXは、上記の最適化を自然にサポートするリバースプロキシサーバーを使用するために特別に設計されています。イベント駆動型の処理メカニズムにより、NGINXは従来のサーバーよりも効率的です。NGINX Plusは、アプリケーションの健康診断、独自のリクエストルーティング、高度なキャッシュ、アフターサービスなど、よりハイエンドのリバースプロキシ機能を追加します。
従来のサーバーとNGINXワーカーの比較
推奨事項2：負荷分散サーバーを増やす
負荷分散サーバーを追加することは比較的簡単ですが、それは大幅にサイトのパフォーマンスとセキュリティを向上させることができます。トラフィックを複数のサーバーに分散することにより、Webサーバーをアップグレードする必要がありません。アプリケーション自体が適切に記述されていないか、拡張が難しい場合でも、負荷分散により、他の変更を加えることなくユーザーエクスペリエンスを向上させることができます。
負荷分散サーバーは、最初はリバースプロキシサーバー（「推奨事項1」を参照）であり、インターネットから他のサーバーへの要求の転送を担当します。ここで重要なのは、負荷分散サーバーが3つ以上のアプリケーションサーバーをサポートし、選択アルゴリズムを使用して異なるサーバー間で要求を分散できることです。最も単純な負荷分散アルゴリズムはラウンドロビンスケジューリングです。これは、使用可能なサーバーの中から次のサーバーに新しい要求を順番に転送します。他のアルゴリズムには、アクティブな接続が最も少ないサーバーへの要求の送信が含まれます。NGINX Plusは、セッション永続性と呼ばれる、ユーザーセッションを同じサーバー上に保持する機能をサポートしています。
負荷分散サーバーは、他のサーバーがアイドル状態であるときに1つのサーバーが過負荷になるのを防ぎ、パフォーマンスを大幅に向上させることができます。同時に、資料を最大限に活用しながら、より安価なサーバーを選択できるため、Webサーバーの拡張も容易になります。
負荷分散を通じてスケジュールできるプロトコルには、HTTP、HTTPS、SPDY、HTTP / 2、WebSocket、FastCGI、SCGI、uwsgi、memcached、およびTCPベースのアプリケーションやその他の第4層プロトコルを含むその他のアプリケーションフォームが含まれます。このためには、最初にWebアプリケーションを分析してパフォーマンスの欠点がどこにあるかを確認し、次にどれを使用するかを決定する必要があります。
同じサーバーまたは負荷分散に使用されるサーバーは、SSL終了、クライアントに応じてHTTP / 1 / xまたはHTTP / 2のサポート、静的ファイルのキャッシュなどの他のタスクを実行することもできます。
NGINXは、負荷分散によく使用されます。詳細については、以前の紹介記事、構成に関する記事、電子書籍と関連するオンラインビデオ、およびもちろんドキュメントを参照してください。当社の商用バージョンであるNGINXPlusは、サーバーの応答時間に基づく負荷分散やMicrosoft NTLMプロトコルをサポートする負荷分散など、より多くの負荷分散機能をサポートしています。
推奨事項3：静的コンテンツと動的コンテンツをキャッシュする
キャッシュメモリは、コンテンツをより迅速にクライアントに配信できるため、Webアプリケーションのパフォーマンスを向上させることができます。キャッシュ戦略には、コンテンツの前処理、より高速なデバイスへのコンテンツの保存、クライアントの近くにコンテンツを保存すること、およびこれらの戦略を同時に適用することが含まれます。
キャッシュには2つのタイプがあります。
-
画像（JPEG、PNG）やコード（CSS、JavaScript）など、頻繁に変更されないファイルである静的コンテンツキャッシュをエッジサーバーに保存して、コンテンツまたはディスクからすばやく取得できます。
-
動的コンテンツキャッシュ、多くのWebアプリケーションは、ページ要求ごとに新しいHTMLを生成し、生成された各HTMLを短期間キャッシュします。これにより、配信されるコンテンツを確保しながら、生成する必要のあるページの総数を大幅に減らすことができます。十分に新鮮です。
ページが1秒間に10回表示され、1秒間キャッシュすると、このページへのリクエストの90％がキャッシュから送信されるとします。静的コンテンツを個別にキャッシュする場合、新しく生成されたページでさえ、キャッシュされたコンテンツから取得される可能性があります。
Webアプリケーションによって生成されたコンテンツをキャッシュするための3つの主要なテクノロジーがあります。
-
コンテンツをユーザーの近くに置きます。ユーザーに近く、送信時間が短くなります。
-
より高速なマシンにコンテンツを配置します。マシンは高速で、検索速度は高速です。
-
使いすぎたマシンからコンテンツを取り除きます。マシンが特定のタスクの実行に集中している場合よりもはるかに遅い場合があります。これは、タスクが多すぎるとマシンの気が散るからです。現時点では、コンテンツを他のマシンに移動することは、キャッシュされたコンテンツだけでなく、キャッシュされていないコンテンツにも適しています。これは、それらをホストするホストの負担が軽減されるためです。
Webアプリケーションのキャッシュは、Webアプリケーションサーバーの内部または外部に実装できます。まず、動的コンテンツをキャッシュして、アプリケーションサーバーの負荷を軽減することを検討してください。次に、静的コンテンツ（動的に生成されたコンテンツの一時的なコピーを含む）にキャッシュを使用して、アプリケーションサーバーの負担をさらに軽減します。次に、アプリケーションサーバーの負担を軽減し、送信時間を短縮するために、キャッシュをより高速またはユーザーに近い他のマシンに移動することを検討してください。
キャッシュを適切に使用すると、アプリケーションの応答速度を大幅に向上させることができます。多くのWebページでは、大きな画像などの静的データがコンテンツの半分以上を占めることがよくあります。キャッシュを使用しない場合、このようなデータのクエリと送信には数秒かかる場合がありますが、キャッシュを使用する場合は、ほんの一瞬しかかかりません。
キャッシュの使用方法を説明する例を示します。NGINXとNGINXPlusは、2つのコマンドを使用してキャッシュを設定します。proxy_cache_pathとproxy_cacheは、キャッシュの場所とサイズ、最大キャッシュ時間、およびその他のパラメーターを指定します。3番目の（そして非常に人気のある）コマンドproxy_cache_use_staleを使用すると、新しいコンテンツを提供するサーバーがビジー状態またはダウンしている場合に、元の古いファイルを提供するようにキャッシュに指示することもできます。クライアントにとっては、コンテンツを取得することをお勧めします。強くなる。ユーザーの観点からは、これにより、サイトまたはアプリケーションの非常に安定したイメージを確立することもできます。
NGINX Plusは、キャッシュのパージや、コントロールパネルを介した視覚的な形式でのキャッシュステータスの表示など、高度なキャッシュ機能をサポートして、リアルタイムの監視を実現します。
NGINXでのキャッシュの詳細については、NGINXPlus管理ガイドのリファレンスドキュメントとNGINXコンテンツのキャッシュを参照してください。
注：キャッシングには、開発、意思決定、運用と保守が含まれます。この記事で説明したような完全なキャッシング戦略は、DevOpsの観点からの価値を反映できます。つまり、開発者、アーキテクト、運用および保守担当者が協力して、Webサイトの機能、応答時間、セキュリティ、およびビジネス目標を確保します。
推奨事項4：データを圧縮する
減圧により、その性能を大幅に向上させることができます。写真、ビデオ、音楽、その他のファイルには、非常に成熟した効率的な圧縮標準（JPEGおよびPNG、MPEG-4、MP3）があり、どの標準でもファイルサイズを1桁以上小さくすることができます。
HTML（プレーンテキストおよびHTMLタグ）、CSSおよびJavaScriptコードを含むテキストファイルは、多くの場合、圧縮せずに転送されます。これらのデータの圧縮は、特にモバイルユーザーのネットワークが低速で不安定な場合に、Webアプリケーションの知覚パフォーマンスを向上させる上で特に明白な場合があります。
マルチメディアデータはケーキの上のアイシングであるのに対し、テキストデータはページの相互作用に必要なサポートの役割を果たすことができるためです。スマートコンテンツ圧縮により、HTML、JavaScript、CSSなどのテキストコンテンツを30％以上削減できるため、それに応じて読み込み時間を短縮できます。
SSLを使用する場合、圧縮によりSSLでエンコードする必要のあるデータの量を減らすことができるため、データを圧縮するためのCPU時間を補正できます。
データを圧縮する方法はたくさんあります。たとえば、RecommendationSixのHTTP / 2の部分では、ヘッダーデータの圧縮に特に適した新しい圧縮のアイデアについて説明しています。テキスト圧縮の例もあります。つまり、NGINXでGZIP圧縮をオンにすることができます。テキストデータを事前に圧縮した後、gzip_staticコマンドを使用して.gzファイルを直接送信できます。
推奨事項5：SSL / TLSを最適化する
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を使用して、それぞれに複数の接続を確立します。2。サーバーが複数の接続を確立する方法は、この問題をさらに悪化させます。
サーバー側でデータを暗号化し、クライアント側でデータを復号化する操作もオーバーヘッドです。
人々に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とNGINXPlusはどちらも、SSL / TLSを終了できます。つまり、他のサーバーとのクリアテキスト通信を維持しながら、クライアント情報の暗号化と復号化を処理できます。これらの手順は、SSL / TLSターミネーションを処理するためにNGINXまたはNGINXPlusで実行できます。TCP接続を受け入れるサーバーでNGINXPlusを使用する場合は、ここでセットアップ手順を参照できます。
推奨事項6：HTTP / 2またはSPDYを実装する
これはSSL / TLSを使用しているサイトであり、HTTP / 2またはSPDYを使用すると、接続ハンドシェイクがある限り、パフォーマンスが向上する可能性があります。SSL / TLS、HTTP / 2、およびSPDYをまだ使用していないサイトの場合、SSL / TLSへの切り替え（通常はパフォーマンスが低下します）は、応答速度の点で一歩後退する可能性があります。
Googleは2012年にSPDYプロジェクトを開始し、HTTP /1.xに加えてより高速な速度を実現することに取り組んでいます。HTTP / 2は、IETFによって最近承認されたSPDYベースの標準です。SPDYは広くサポートされていますが、まもなくHTTP / 2に置き換えられます。
SPDYとHTTP / 2の鍵は、複数の接続ではなく1つの接続のみを使用することです。この1つの接続は多重化されているため、複数の要求と応答を同時に運ぶことができます。
1つの接続のみが維持されるため、複数の接続に必要なセットアップと管理の消費が節約されます。また、SSL / TLSが安全な接続を確立するために必要なハンドシェイク時間を最小限に抑えることができるため、接続はSSLにとって特に重要です。
SPDYプロトコルではSSL / TLSを使用する必要があり、HTTP / 2には正式な要件はありませんが、現在HTTP / 2をサポートしているすべてのブラウザーは、SSL / TLSが有効になっている場合にのみ使用します。つまり、HTTP / 2をサポートするブラウザは、WebサイトがSSLを使用し、サーバーがHTTP / 2トラフィックを受け入れる場合にのみ、HTTP / 2を使用します。それ以外の場合、ブラウザはHTTP /1.xに基づいて通信します。
SPDYまたはHTTP / 2が実装された後は、ドメイン名のセグメンテーション、リソースのマージ、画像スプライトなど、HTTPの以前のパフォーマンス最適化手段は不要になります。したがって、コードとデプロイメントを簡素化できます。HTTP / 2によってもたらされる変更については、ホワイトペーパーを参照してください。
NGINXは非常に早い段階でSPDYをサポートしており、現在SPDYを使用しているほとんどのサイトでNGINが実行されています。
バツ。NGINXはHTTP / 2をサポートする最初の企業でもあります。2015年9月、NGINXオープンソースとNGINXPlusはHTTP / 2のサポートを開始しました。
時間が経つにつれて、NGINXはほとんどのサイトがSSLを有効にし、HTTP / 2に移行することを望んでいます。これにより、サイトがより安全になるだけでなく、新しい最適化手法が出現し続けるにつれて、単純なコードによってより高いパフォーマンスを実現することもできます。
推奨事項7：ソフトウェアをアップグレードする
ソフトウェアの信頼性とパフォーマンスに基づいて選択された、アプリケーションパフォーマンスリットルの簡単な方法を提供します。さらに、高品質のコンポーネントの開発者は、パフォーマンスを継続的に改善し、問題を修正する可能性が高いため、最新の安定バージョンを使用することは費用効果が高くなります。新しくリリースされたバージョンは、開発者とユーザーからより多くの注目を集め、新しいハードウェアの調整など、新しいコンパイラ最適化手法も利用します。
古いバージョンと比較して、新しくリリースされた安定バージョンは大幅に高いパフォーマンスを発揮します。アップグレードを継続し、チューニング、問題の修復、およびセキュリティアラートの時間に遅れないようにすることもできます。
ソフトウェアのアップグレードに失敗すると、新しい機能の使用も妨げられます。たとえば、HTTP / 2には現在OpenSSL1.0.1が必要です。2016年の後半から、HTTP / 2には2015年1月にリリースされたOpenSSL1.0.2が必要になります。
NGINXユーザーは、最新バージョンのNGINXオープンソースソフトウェアまたはNGINX Plusから始めることができます。これは、ソケット共有、スレッドプール（以下を参照）をサポートし、引き続きパフォーマンスを最適化します。したがって、ご使用のソフトウェアを確認して、最新バージョンにアップグレードしてみてください。
推奨事項8：Linuxのチューニング
Lの性能を向上させるすべてのインフラストラクチャの基盤、Linuxが重要であるとしてinuxは、今日、ほとんどのWebサーバ基盤となるオペレーティングシステムです。デフォルトでは、多くのLinuxシステムは比較的保守的であり、要件としてデスクトップオフィスのみに依存し、チューニングの目標として少量のリソースを使用します。Webアプリケーションの場合、最高のパフォーマンスを実現するには、再調整する必要があります。
Linuxの最適化は、Webサーバーごとに異なります。NGINXを例にとると、次の側面を考慮することができます。
在庫キュー。一部の接続を処理できない場合は、net.core.somaxconnを増やすことができます。これは、NGINXが処理するのを待機している接続の最大数です。この接続制限が小さすぎると、エラーメッセージが表示されます。エラーメッセージが表示されなくなるまで、この値を徐々に増やすことができます。
-
ファイル記述子。NGINXは、接続ごとに最大2つのファイル記述子を使用します。システムが多くの接続を提供する場合、増加した負荷をサポートするために、記述子のsys.fs.file_maxシステムレベルの制限とnofileユーザーファイル記述子の制限を増やす必要がある場合があります。
-
一時的なポート。NGINXをプロキシとして使用すると、アップストリームサーバーごとに一時ポートが作成されます。net.ipv4.ip_local_port_rangeを設定して、ポート値の範囲を拡大し、使用可能なポートの数を増やすことができます。さらに、net.ipv4.tcp_fin_timeoutの値を減らすこともできます。これは、非アクティブなポートの解放と再利用の待機時間を制御し、ターンオーバーを高速化します。
-
NGINXについては、NGINXパフォーマンスチューニングガイドを参照して、Linuxシステムを簡単に最適化してスループットを向上させる方法を確認してください。
推奨事項9：Webサーバーの調整
いいえどのWebサーバーで、それらの調整を申請する必要があります。次の提案はすべてのWebサーバーに適用されますが、NGINXのみをセットアップするための手順が示されます。
-
アクセスログ。要求されたすべてのログをすぐにディスクに書き込まないでください。メモリにキャッシュしてからバッチ処理できます。NGINXの場合、buffer = _size_パラメータがaccess_log命令に追加され、メモリバッファがいっぱいになった後にログがディスクに書き込まれます。** 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：リアルタイムのダイナミクスを監視して、問題とボトルネックを見つけます
Paulの重要なアプリケーションは、アプリケーションパフォーマンスの高性能リアルタイムモニタリングを保存します。対応するWebインフラストラクチャ内の特定のデバイスとアプリケーションのダイナミクスをリアルタイムで監視する必要があります。
サイトの活動を監視することはほとんど受動的であり、何が起こったのかを伝えるだけです。問題を見つけて解決する方法については、それはあなた自身の仕事です。
監視により、次のタイプの問題を検出できます。
1.サーバーがダウンしています
2.サーバーが不安定で、接続が失われている
3.サーバーにキャッシュ障害の広い領域があります
4.サーバーから送信されたコンテンツが正しくない
New RelicやDynatraceなどのグローバルパフォーマンスモニタリングツールは、リモートページの読み込み時間を監視するのに役立ち、NGINXはアプリケーション配信側を監視するのに役立ちます。アプリケーションのパフォーマンスデータは、最適化方法が実際にユーザーに異なるエクスペリエンスをもたらす時期と、ますます多くのトラフィックに対応するために容量を拡張する必要がある時期を示します。
NGINX Plusは、ユーザーができるだけ早く問題を見つけられるようにするために、頻繁に発生する問題を報告するアプリケーションの身体検査機能を追加しました。NGINX Plusには、既存のタスクが完了する前に新しい接続を防止するセッションドレイン機能と、復元されたサーバーが負荷分散クラスターで目的の速度に到達できるように容量をスロースタートする機能もあります。ヘルスチェックを適切に使用すると、ユーザーエクスペリエンスに大きな影響を与える前に問題を特定するのに役立ちます。一方、セッションのドレインとスロースタートにより、知覚されるパフォーマンスやオンライン時間に影響を与えることなくサーバーを交換できます。この図は、サーバー、TCP接続、およびキャッシュをカバーする、NGINXPlusの組み込みのリアルタイムアクティビティ監視コントロールパネルを示しています。
結論：パフォーマンスが10倍向上
セックスは改善することができます異なるWebアプリケーションのために大きな違いがあります。実際の改善は、予算、時間、および現在の実装と理想的なパフォーマンスの間のギャップによって異なります。では、どのようにしてアプリケーションのパフォーマンスを10倍向上させるのでしょうか。
各最適化提案の可能性を理解しやすくするために、以下に以前の提案の実装ガイドラインをいくつか示します。必要なものが得られることを願っています。
-
リバースプロキシサーバーと負荷分散。ロードバランシングまたはプールロードバランシングがないと、パフォーマンスが極端に低下する可能性があります。NGINXなどのリバースプロキシサーバーを追加すると、Webアプリケーションのメモリとディスク間のラウンドトリップを減らすことができます。負荷分散は、過負荷のサーバーからアイドル状態のサーバーにタスクを転送でき、拡張にも便利です。これらの変更により、パフォーマンスを大幅に向上させることができます。元の展開方法の最悪の場合と比較して、10倍未満であっても、全体として10倍のパフォーマンス向上は非常に簡単です。
-
動的コンテンツと静的コンテンツをキャッシュします。Webサーバーがアプリケーションサーバーとしても機能する場合は、動的コンテンツをキャッシュすることで、ピーク時に10倍のパフォーマンス向上を実現できます。静的コンテンツをキャッシュすると、パフォーマンスが数倍向上することもあります。
-
データを圧縮します。JPEG、PNG、MPEG-4、MP3などの圧縮形式を使用すると、パフォーマンスを大幅に向上させることができます。これらの方法を使用すると、圧縮されたテキストデータ（コードとHTML）によって最初のページの読み込み時間が2倍になる可能性があります。
-
SSL / TLSを最適化します。安全なハンドシェイクはパフォーマンスに大きな影響を与えるため、それを最適化すると、特にテキストコンテンツが多いWebサイトの場合、初期応答が2倍速くなります。SSL / TLSでメディアファイルを最適化することによってもたらされるパフォーマンスの向上はごくわずかです。
-
HTTP / 2とSPDYを実装します。SSL / TLSを使用する場合、これら2つのプロトコルにより、Webサイトの全体的なパフォーマンスが向上する可能性があります。
-
LinuxとWebサーバーのチューニング。最適化されたバッファリング戦略を使用し、アクティブな接続を使用し、時間のかかるタスクを独立したスレッドプールにリロードすると、パフォーマンスを大幅に向上させることができます。たとえば、スレッドプールは、ディスクを大量に消費するタスクのパフォーマンスを少なくとも1桁向上させることができます。
上記のテクニックをご自身でお試しいただき、パフォーマンス向上の経験を共有していただければ幸いです。
------------------------------------------- <終了> ---- -----------------------------------
翻訳者：それのために書く
出典：www.zcfy.cc/article/10-tips-for-10x-application-performance-nginx-22.html
オリジナル：https：//www.nginx.com/blog/10-tips-for-10x-application-performance/