調整に関しては、1つの方法がすべてに適しているわけではありません。 最適な設定を決定するさまざまな要因があります。 BizTalk Server には、バックログの超過からシステムを効果的に保護するためのテストによって証明された既定値が用意されています。 ただし、一部のシナリオでは、これは攻撃的すぎる可能性があります。 次の例は、この点を示しています。
例 1: ピーク時の読み込みとデータベース サイズ
BizTalk Server 上に構築された各ソリューションには、最大の持続可能なスループット (MST) があります。 負荷がこのレベルを下回っている限り、システムは定義上、その負荷を無期限に維持できます。 ただし、実際には、負荷プロファイルにピークと谷がある方が、時間の経過と伴って変化しない安定した荷重を持つよりも一般的です。
最高のピーク負荷を無期限に維持できるシステムを構築するのではなく、ピーク負荷の下でバックログを処理し、谷の間に復旧できるシステムを構築する方がコスト効率が高くなります。 ただし、ピーク時に予想されるバックログがデータベース サイズの既定の調整値よりも高い場合、システムは入力を調整することによってバックログをブロックします。 たとえば、すべての入力ファイルをできるだけ早く使用する必要があるため、これが望ましくない場合、解決策は、調整の前に予想されるバックログを受け入れるようにデータベース サイズのしきい値を上げることです。
例 2: メモリ使用量の最適化
処理速度を測定するために調整が使用するもう 1 つのリソースは、ホスト プロセスで使用可能なメモリの量です。 使用可能なメモリがしきい値と比較して小さくなりすぎた場合、スロットリングによってエンジンがホストキューから取得するメッセージ数が制限されます。 現在のエンタープライズ クラス サーバー (特に BizTalk Server での x64 サポートを使用) でのメモリの量と可用性の変動を考えると、メモリ使用量を最適化するためにしきい値を上げたり下げたりする必要がある場合があります。
勧告
BizTalk Server でのスロットリングは、既定の構成によってシステムを自動で適切に保護するようになっています。 ただし、既定の設定は、最適と見なすべきではありません。 調整状態のパフォーマンス カウンターを監視して調整が行われているかどうかを確認し、調整が基になっているリソース (データベース サイズやメモリ使用量など) が使用率の下または過剰であるかどうかを自分で判断し、それに応じて調整しきい値を調整します。