IISサーバーのパフォーマンス、実行できない10のことに注意してください。

IISサーバーのパフォーマンスは作業効率に関係するため、IISサーバーのパフォーマンスを妨げる方法はありませんが、それでも多くの人が失敗してIISのパフォーマンスが低下します。さて、あなたができないことをチェックしてください。

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が提供されているため、スレッドプールモデルはより効果的に機能します。ワーカースレッドプールは要求列を処理します。