ユーザ数の予測と対処
ArcGIS Server の特長は、さまざまな場所にいる多数のユーザに GIS 機能を提供できることにあります。GIS サーバの計画を立てる際には、システムを使用するユーザの数と、それらのユーザをサポートするのにハードウェアがどれくらい必要かを割り出してください。また、使用が集中するかどうかといったその他の要因も考慮に入れる必要があります。ハードウェアを増設するという選択肢がない場合は、サービス構成を調整することで、より多くのユーザに対処できる可能性があります。
SOC コンピュータによる対処
サーバの GIS タスク は SOC（Server Object Container）コンピュータで実行されます。処理の負荷が高い時間帯は、一般に、SOC の CPU 使用率が SOM（Server Object Manager）や Web サーバよりも先に 100% に達します。このため、導入する SOC コンピュータの数を決定することは、ユーザに対応するための重要な決断の 1 つです。
必要な SOC コンピュータの数を選択するには、サービスで同時に処理を行う必要のあるユーザの最大数について検討します。平均的なスペックのコンピュータの 1CPU はアクティブ サービス インスタンスを 4 つ同時にサポートできます。つまり、最大で 4 人のユーザがサービスで同時に処理を行うことができます。アイドル状態のサービスはこの数に含めないでください。ArcGIS Server 開発者は常に、GIS 操作の終了直後にサーバ コンテキストを解放するためのコードを追加する必要があります。
この数字はあくまでも指針にすぎず、ユーザがサーバ上で実行する操作の複雑さやユーザが操作するデータによって異なる可能性があります。システムの運用を開始した後は、ログ ファイルとサーバの統計情報に基づいて、さらにシステムのサイジングとチューニングを行うことができます。システムのピーク時に SOC への標準的なリクエストがタイムアウトすることが判明し、CPU の使用率が 100% に達している場合は、おそらく SOC 層で CPU を増設するのが効果的です。
負荷が大きなサーバのパフォーマンスについてテストしたり結論を導き出したりする前に、Web サービスでリクエストごとの偽装を回避するようにサーバを設定しているか確認してください。1 秒当たりの同時リクエストが 25 件を超えるような場合は、Local Security Authority Subsystem Service（lsass.exe）に過大な負荷が加わって、サーバのパフォーマンスが低下する可能性があります。Esri Knowledge Base Articles 32620（Windows Server 2003）または 32622（Windows XP）で、この状況を回避する方法が説明されています。
システムのサイジングの詳細については、http://www.esrij.com/products/document/tech_p_index.html（日本語版）または http://www.esri.com/systemdesign（英語版）にアクセスして、最新の技術資料『システム設計ガイド（System Design Strategies）』をご参照ください。
サービス プロパティの調整による対処
システムのハードウェアを増設するという選択肢がない場合でも、サービスのプロパティを適切に設定することで、より多くのユーザに対処できる可能性があります。
たとえば、すべてのサービスにはインスタンスの最大数を設定するプロパティがあります。このプロパティは、同時に実行できるサービス インスタンスの最大数を表します。管理者は、予想される数のユーザに適切なパフォーマンスで対応するためのサービス インスタンスの数を割り出す必要があります。これは、クライアントによるサービスの平均使用時間、予想されるクライアントの数、クライアントのリクエストの頻度、およびリクエストに必要な処理の負荷からなる、複雑な評価です。
あるコンフィグレーションに必要なサービスの数を割り出すとしたら、試行錯誤を繰り返すのがおそらく最善の方法です。クライアントの待機時間が長すぎてリクエストがタイムアウトする場合は、利用可能なサービスの数やアプリケーションによるサービスの使用方法を調整する必要があるでしょう。クライアントをサポートするサービスの数を決定したら、このコンフィグレーションのサービス インスタンスの最大数をその数に設定します。これにより、システムの残りのリソースを他のサービス構成とそれらがサポートするクライアントに回すことができます。
サービスには、インスタンスの最小数を示すプロパティもあります。このプロパティは、ユーザの使用がないときにも作成され利用可能となっているサービスの数を表します。多くのユーザがプールされるサービスを同時に使用するのでなければ、インスタンスの最小数に小さい値を設定することを検討してください。インスタンスの最小数を 0 に設定することもできます。
場合によっては、外部の事象が特定のサービスの使用を促すことがあります。たとえば、自然災害によって危機管理アプリケーションに特定のサービスへのリクエストが殺到することがあります。このような場合は、ArcGIS Server の使用環境を最適化するために、そのサービスのインスタンスの最大数を引き上げて、利用可能なサーバ リソースをすべて割り当てるのが得策かもしれません。そうすると、サービスはシステム全体を利用できるようになります。ArcGIS Server は「プールの縮小」機能を提供します。この機能は、使用頻度の高いサービス構成を優先して、使用頻度の低いサービス構成のインスタンスの数を自動的に削減します。
また、ユーザがサービスを使用する時間の長さについても検討する必要があります。サーバへのリクエストの中には、他のリクエストよりも負荷の高いものがあります。サービスに負荷の低いリクエストが大量に送信された場合よりも、負荷の高いリクエストがいくつか送信された場合のほうが、サービスのパフォーマンスを低下させることがあります。各サービスには、最大待機時間と最大使用時間を設定するプロパティがあります。サービスへのリクエストがタイムアウトを繰り返している場合は、サービスの最大待機時間または利用可能なサービス インスタンスの数を増やすことを検討してください。
ログ ファイルとサーバの統計情報を使用して、タイムアウトするリクエストの数が多いかどうか、サービスの使用時間が最大使用時間を超えているかどうかを判断することができます。ArcGIS Server Manager または ArcCatalog を使用して、利用可能なサービスの数とサービスの最大使用時間を調整することができます。