IISサーバーのパフォーマンスを低下させるための10のルール

以下の各ルールは、コードのパフォーマンスと拡張性に効果的な影響を与えます。言い換えれば、戒めに従わないようにしてください！以下では、パフォーマンスとスケーラビリティを向上させるためにそれらを破棄する方法を説明します。

1.複数のオブジェクトを割り当てて解放する必要があります。

メモリの割り当てにはコストがかかる可能性があるため、メモリの過剰割り当てを避けるようにしてください。ほとんどの割り当て演算子は常に隣接する解放されたメモリブロックをより大きなブロックに接続しようとするため、メモリブロックを解放するとよりコストがかかる可能性があります。 WindowsNT®4.0 Service Pack 4.0がマルチスレッド処理で実行されるまで、システムヒープは通常ひどく機能しません。ヒープはグローバルロックによって保護されており、マルチプロセッサシステムでは拡張できません。

2.プロセッサキャッシュの使用を検討すべきではありません。しかし、他のメモリアクセス方法に違いはないと多くの人が考えています。 80486以来、この見方は間違っています。最新のCPUはRAMよりはるかに高速で、RAMは最低2レベルのメモリキャッシュを必要とし、高速のL1キャッシュは8KBのデータと8KBの命令を保持でき、低速のL2キャッシュは数百キロバイトのデータとコードを保持できます。一緒に。 Ｌ１キャッシュ内のメモリ領域への参照は１クロックサイクルかかり、Ｌ２キャッシュへの参照は４〜７クロックサイクルかかり、メインメモリへの参照は多くのプロセッサクロックサイクルを必要とする。後者の数はすぐに100クロックサイクルを超えるでしょう。多くの点で、キャッシングは小型で高速の仮想メモリシステムのようなものです。

キャッシュに関連する基本的なメモリ単位は、バイトではなくキャッシュ列です。 Pentiumキャッシュ列は32バイト幅です。 Alphaキャッシュ列は64バイト幅です。これは、コードとデータ用にL1キャッシュに512スロットしかないことを意味します。複数のデータが一緒に使用され（時間位置）、一緒に保管されない（空間位置）場合、パフォーマンスは低下します。配列の空間的位置は良く、相互接続リストのリストや他のポインタベースのデータ構造は貧弱な傾向があります。

同じキャッシュ列にデータをパッケージ化すると、通常はパフォーマンスが向上しますが、マルチプロセッサシステムのパフォーマンスも低下します。メモリサブシステムがプロセッサ間キャッシュを調整することは困難です。すべてのプロセッサによって使用される読み取り専用データが、1つのプロセッサによって使用され頻繁に更新されるデータとキャッシュ列を共有する場合、キャッシュはキャッシュされた列のコピーを更新するのに長い時間がかかります。このピンポン高速ゲームはしばしば「キャッシュスロッシング」と呼ばれる。読み取り専用データが別のキャッシュ列にある場合は、スロッシングを回避できます。

コードのスペース最適化は、スピード最適化よりも効率的です。コードが少なければ少ないほど、コードが占有するページも少なくなります。これにより、必要な実行設定とページフォルトが少なくなり、キャッシュ列も少なくなります。ただし、一部のコア機能は速度を最適化する必要があります。プロファイラーを使用してこれらの機能を識別できます。 3.頻繁に使用するデータをキャッシュしないでください。ソフトウェアキャッシングは、様々なアプリケーションによって使用され得る。計算が高価な場合は、結果のコピーを保存してください。これは典型的な時空間の妥協案です。記憶域をいくらか犠牲にして時間を節約してください。うまくいけば、このアプローチは非常に効果的です。

正しくキャッシュする必要があります。間違ったデータがキャッシュされていると、ストレージスペースが無駄になります。キャッシュしすぎると、他の操作に使用できるメモリはほとんどなくなります。キャッシュが少なすぎると、キャッシュされたデータを再計算しなければならないため、効率は低くなります。時間に敏感なデータが長期間キャッシュされると、データは古くなります。一般に、サーバーはスペースよりもスピードを重視するので、デスクトップシステムよりもキャッシュが多くなります。未使用のキャッシュを定期的に削除するようにしてください。そうしないと、実行設定に問題が生じる可能性があります。

4.複数のスレッドを作成したほうが良いでしょう。

サーバーで動作するスレッド数を調整することが重要です。スレッドがI /Oバウンドの場合、I /Oの完了を待つのに長い時間がかかります - ブロックされたスレッドは有用な仕事をしないスレッドです。スレッドを追加するとスループットが向上しますが、スレッドを追加しすぎるとコンテキストスワッピングが大きなオーバーヘッドになるため、サーバーのパフォーマンスが低下します。コンテキスト交換速度が遅い理由は3つあります。コンテキスト交換は純粋なオーバーヘッドであり、アプリケーションの作業には利点がない、コンテキスト交換が貴重なクロックサイクルを使い果たす、最悪の場合、コンテキスト交換がプロセッサのキャッシュをいっぱいにする無駄なデータの場合、このデータを置き換えるのはコストがかかります。

あなたのスレッド構造に依存することがたくさんあります。クライアントごとに1つのスレッドは絶対に不適切です。多数のクライアントに対してスケーラブルではないからです。文脈交換は耐え難くなり、Windows NTはリソースを使い果たしました。 Windows 2000ではQueueUserWorkItemなどの対応するAPIが提供されているため、スレッドプールモデルはより効果的に機能します。ワーカースレッドプールは要求列を処理します。 5.データ構造にグローバルロックを使用すべきです。

データスレッドを安全にする最も簡単な方法は、大きなロックをかけることです。簡単にするために、すべてのものが同じロックを使用します。このアプローチには問題があります：直列化。ロックを取得するには、データを処理したいすべてのスレッドがインラインで待機しなければなりません。スレッドがロックによってブロックされている場合は、何も役に立ちません。一度に1つのスレッドだけがロックを必要とするため、この問題はサーバーの負荷が軽い場合は一般的ではありません。負荷が大きい場合は、ロックをめぐる激しい競争が大きな問題になる可能性があります。

高速道路上のすべての車両が狭い道路に向けられている多車線高速道路での事故を想像してみてください。車両が小さい場合、交通量の割合に対するこの移行の影響はごくわずかです。たくさんの車がある場合、車がゆっくりとその単一の車線に合流すると、交通渋滞は何マイルも続くことがあります。

ロック競合を減らすことができるいくつかのテクニックがあります。

・過剰に保護しないでください。つまり、データをロックする必要はありません。あなたがそれを必要とするときだけ、ロックを握ってください、そして、時間がかかりすぎないでください。大量のコードや頻繁に実行されるコードの周囲でロックを使用しないことが重要です。
・別のロックで保護できるようにデータを分割します。たとえば、名前がQで始まるシンボルの値が変更されたときに名前がHで始まるシンボルの値が読み取られないように、シンボルテーブルを識別子の最初の文字で分割することができます。
・ロックを必要とせずにデータを自動的に変更するには、インターロックされた一連のAPI（InterlockedIncrement、InterlockedCompareExchangePointerなど）を使用します。
・データが頻繁に変更されない場合は、マルチリーダー/シングルライターロックを使用できます。ロック操作のコストは高くなりますが、作成者に飢えが生じる恐れがありますが、同時実行性は向上します。
・重要な部分でループカウンターを使用します。 Windows NT 4.0 Service Pack 3のSetCriticalSectionSpinCount APIを参照してください。
・ロックを取得できない場合は、TryEnterCriticalSectionを使用してその他の便利な作業を行ってください。
競争が激化するとシリアライゼーションが発生し、シリアライゼーションはCPU使用率の低下につながります。このため、ユーザーがより多くのスレッドに参加するようになり、状況は悪化します。

6.マルチプロセッサマシンに注意を払わないでください。

シングルプロセッサシステムよりもマルチプロセッサシステムの方がコードの実行速度が悪くなります。物事当然のことながら、N次元システムでN回実行するほうが良いでしょう。パフォーマンスが低下する理由は、競合（ロック競合、バス競合、および/またはキャッシュ列競合）です。プロセッサは、より多くの作業をするのではなく、共有リソースの所有権を争っています。

マルチスレッドアプリケーションを作成する必要がある場合は、マルチプロセッサボックスを使用してアプリケーションの強度テストとパフォーマンステストを実行する必要があります。シングルプロセッサシステムは、タイムスライスでスレッドを実行することによって、幻想的な錯覚を与えます。マルチプロセッサボックスには真の同時実行性があり、競争の激しい環境と競争が起こりやすくなります。 7.モジュラーコールは常に使用されるべきです;それらはおもしろいです。

同期モジュラー呼び出しを使用してI /O操作を実行することは、ほとんどのデスクトップアプリケーションに適しています。ただし、サーバー上のCPUを使用するのは良い方法ではありません。 I /O操作は完了するのに数百万クロックサイクルかかります、そしてこれらのクロックサイクルはよりよく利用されたかもしれません。非同期I /Oを使用すると、ユーザー要求率とI /Oスループットを大幅に向上させることができますが、さらに複雑さが増します。

時間がかかるモジュラー呼び出しやI /O操作がある場合は、それらに割り当てられているリソース量をテストする必要があります。すべてのスレッドを使用しますか、それとも制限がありますか？一般に、限られた数のスレッドを使用することをお勧めします。モジュラー呼び出しを完了するためのスレッドの作業をスケジュールするためにキューを使用して、小さなスレッドプールとキューを作成します。このようにして、他のスレッドがあなたのモジュール式ではない要求を拾って処理することができます。

8.測定しないでください

話していることを測定してそれを数字で表現することができれば、それはあなたが彼をある程度理解していることを意味します。表現するとき、あなたの知識は不満足で不満足です;これは知識の始まりかもしれませんが、あなたが科学のレベルにあなたの心を上げることは単に不可能です。

- ケルビン卿（William Thomson）

測定しなければ、アプリケーションの機能を理解できません。あなたは暗闇の中で推測しています。パフォーマンスの問題を特定しなければ、改善やワークロード計画を立てることはできません。

測定にはブラックボックス測定とプロファイリングが含まれます。ブラックボックス測定とは、パフォーマンスカウンタ（メモリ使用量、コンテキスト交換、CPU使用率など）および外部検査ツール（光束、反射時間など）によって表示されるデータを収集することを意味します。コードをプロファイルするには、ツールバージョンのコードをコンパイルしてからさまざまな条件下で実行し、実行時間とプロセス呼び出しの頻度に関する統計を収集します。

分析に使用されない場合、測定は役に立ちません。測定は、問題があることを知らせるだけでなく、問題がどこにあるのかを判断するのにも役立ちますが、なぜ問題があるのか​​を判断することはできません。問題を分析して、正しく修正できるようにしてください。表面にとどまるのではなく、根本的に問題を解決することが必要です。

変更を加えるときは、再測定する必要があります。変更が有効かどうかを知る必要があります。変化はまた他の性能問題を露呈するかもしれず、そして測定 - 分析 - 補正 - 再測定サイクルは最初からやり直されるであろう。パフォーマンス低下の問題を見つけるためにも定期的に測定を行う必要があります。 9.シングルユーザー、シングルリクエストのテスト方法を使用する必要があります。

ASPおよびISAPIアプリケーションを作成する際の一般的な問題は、1つのブラウザでアプリケーションをテストすることです。彼らがインターネットで彼らのプログラムを適用したとき、彼らは彼らのアプリケーションが高負荷を扱うことができないことを発見し、そしてスループットと応答時間は哀れでした。

ブラウザによるテストは必要ですが十分ではありません。ブラウザが十分に速く反応しない場合、あなたは問題を抱えていることを知っています。しかし、ブラウザを使用しているときは高速であっても、それが負荷をどの程度うまく処理しているかはわかりません。 1ダース以上のユーザーが同時に要求した場合はどうなりますか？百？アプリケーションはどのようなスループットを許容できますか？どのような反応時間がありますか？軽負荷時にこれらの数値はどうなりますか？中負荷はどうですか？重い負荷？マルチプロセッサマシン上のアプリケーションはどうなりますか？アプリケーションの強度テストは、バグを見つけてパフォーマンスの問題を見つけるための基本です。
同様の負荷テストの考慮事項がすべてのサーバーアプリケーションに適用されます。

10.実際の環境は使用しないでください。

人々は少数の特定の人工的な環境（ベンチマークなど）でのみアプリケーションを調整する傾向があります。実際の状況に対応するさまざまな状況を選択し、操作の種類ごとに最適化することが重要です。あなたがこれをしないなら、あなたのユーザーと評論家は間違いなくこれをします、そして、彼らはあなたのアプリケーションの品質を判断するためにこれを使います。

zh-CN"],null,[1],zh-TW"]]]