3

毎月約 400 万人のユーザーがいるかなり人気のあるサイトがあります。これは、16 GB の RAM、24 コアの 2 プロセスを備えた専用ボックスでホストされています。

いつでも CPU は常に 40% 未満で、メモリは 12 GB 未満ですが、トラフィックが最大になるとパフォーマンスが非常に低下します。サイトは非常に遅いです。メイン サイト用とフォーラム用の 2 つのアプリ プールがあります。サイトだけが遅いです。アプリ プールごとの CPU やメモリに制限はありません。

パフォーマンス カウンターを調べたところ、非常に興味深いことがわかりました。なんらかの理由でピーク時にリクエストがキューに入れられています。全体的なコンテキスト切り替えの数は、約 30 ～ 110,000 k と非常に高くなります。

私が理解しているように、コンテキストの切り替えが多いのはロックが原因です。多数のコンテキスト スイッチが発生するサンプル コードを教えてください。

4

1 に答える 1

1

私はコンテキストの切り替えにあまり関心がありませんし、数が膨大だとは思いません。IIS で多数のスレッドが実行されており (24 コアのマシンであるため)、コンテキスト切り替えの数値が高くなることが予想されます。ただし、リクエストのキューイングには間違いなく関心があります。

私はいくつかのことを行い、それがパフォーマンス カウンターにどのように影響するかを確認します。

  1. 常に 40% 未満で実行しているため、サーバーの CPU は明らかに十分に活用されていません。使用率が 50 ～ 60% になるまで、IIS の「プロセッサ制限あたりのスレッド数」の値を高く設定してみてください。本によるコアあたりのスレッド数の最適値は 20 ですが、これはシナリオによって異なり、これより高い値または低い値を試すことができます。>=30 の値を設定することをお勧めします。CPU 使用率が低い場合も、IO 操作がブロックされている兆候である可能性があります。
  2. IIS プロパティで「キューの長さ」の設定を調整します。「プロセッサ制限あたりのスレッド数」を 20 に設定した場合、キューの長さを 20 x 24 コア = 480 に設定する必要があります。他のリクエストの処理がブロックされているか、IO 応答の待機がブロックされています。
  3. IIS から静的ファイルを提供しないでください。それらをCDN、Amazon S3、またはその他に移動します。これにより、サーバーのパフォーマンスが大幅に向上します。1,000 のサーバー リクエストが別の場所に送られるからです。IIS からファイルを提供する必要がある場合は、IIS ファイル圧縮を構成します。さらに、静的コンテンツに有効期限ヘッダーを使用して、クライアントにキャッシュされるようにします。これにより、帯域幅が大幅に節約されます。
  4. ASP.NET コントローラー、ハンドラーなどで可能な限り Async IO (ディスク、データベース、ネットワークなどからの読み取り/書き込み) を使用して、スレッドを最適に使用していることを確認します。ブロッキング IO を使用して使用可能なスレッドをブロックすると (これは、私がこれまでに見た ASP.NET アプリの 95% で行われています)、スレッド プールが高負荷下で完全に使用され、キューイングが発生する可能性があります。
  5. サーバーにヒットするリクエストの数と、単一のリクエストの処理時間を防ぐために、一般的な最適化を行います。これには、CSS/JS ファイルの縮小とバンドル、Javascript のリファクタリングによるサーバーへのラウンドトリップの削減、コントローラー/ハンドラー メソッドのリファクタリングによる高速化などが含まれます。Google と Yahoo の推奨事項へのリンクを以下に追加しました。
  6. IIS で ASP.NET デバッグを無効にします。

Google および Yahoo の推奨事項:

https://developers.google.com/speed/docs/insights/rules

https://developer.yahoo.com/performance/rules.html

これらすべてのアドバイスに従えば、改善が得られると確信しています。

于 2014-09-17T21:28:53.530 に答える