ジオプロセシング サービスのパフォーマンスのヒント
ジオプロセシング サービスは、高速かつ効率的である必要があります。クライアントは高速なサービスを望み、期待します。ArcGIS Server は一度に複数のクライアントに対処できるため、効率の悪いサービスによってサーバが過負荷状態になる可能性があります。サービスの効率がよいほど、同じコンピュータ リソースを使って対処できるクライアントの数が増えます。
次に、サービスのパフォーマンスを向上させるためのヒントと手法を示します。ここでは、これらの手法をパフォーマンスの向上率が高いものから順に示します。最後に示すいくつかのヒントは実行時間を何秒か短縮することができます。一部のタスクでは、それが必要になるかもしれません。
ローカル ジョブ ディレクトリの使用
ArcGIS Server の構成に複数のコンピュータが含まれる場合は、各コンピュータでローカル ジョブ ディレクトリを設定します。これにより、実行時間が大幅に短縮されます。ローカル ジョブ ディレクトリを設定するのはシステム管理者です。
データおよびリソースへのローカル パスの使用
可能であれば、サービスによって使用されるデータをローカル エリア ネットワーク（LAN）に分散させるのではなく、サービスを実行しているコンピュータに格納してください。LAN に分散されたデータの読み取りには、ローカル ディスクからの読み取りよりも時間がかかります。パフォーマンスを示す数字はさまざまですが、おおよそ、LAN 経由でデータを転送するとローカル ディスクの場合の 2 倍の時間がかかります。
データのメモリへの書き込み
中間データはメモリに書き込むことができます。データをメモリに書き込むほうが、ディスクに書き込むよりも高速です。結果マップ サービスを使用している場合を除き、出力データもメモリに書き込むことができます。ラスタをメモリに書き込むことはできません。
Esri Grid ラスタ形式の使用
ArcGIS はさまざまなラスタ データ形式をサポートしています。タスクでラスタ データを使用する場合は、通常、ラスタ データを GRID 形式で格納し、すべてのモデル プロセスに GRID を操作させる必要があります（[ラスタ → 他のフォーマット（Raster to Other Format）] ツールまたは [ラスタのコピー（Copy Raster）] ツールを使用して、GRID 形式へとラスタを前処理できます）。通常、GRID 形式はその他のラスタ タイプと比べて処理がより高速になりますが、サポートされているラスタ タイプであればいずれもモデルおよびスクリプト内で使用することができます。
ラスタ データを GRID 形式で格納できない場合は、モデルまたはスクリプト内で [ラスタのコピー（Copy Raster）] ツールを使ってラスタの一部をコピーし、その限定されたエリアのみを処理することができます。ラスタの一部をコピーするには、[ラスタのコピー（Copy Raster）] ツールを使ってジオプロセシングの出力範囲環境を設定します。これにより、範囲内のセルだけがコピーされます。
ソース マップ ドキュメント内のレイヤの使用
サービスがソース マップ ドキュメントを使用する場合、モデルとスクリプトではソース マップ ドキュメント内のレイヤを使用することができます。レイヤはディスク上のデータセットを参照し、一部のレイヤはデータセットに関するプロパティをキャッシュします。この動作は特にネットワーク データセット レイヤに当てはまります（「GP サービス サンプル: 走行時間ポリゴン」を参照）。データセットの代わりにネットワーク データセット レイヤを使用すると、ArcMap がデータセットを 1 回開いて、データセットの基本プロパティをキャッシュし、データセットを開いたままにするので、パフォーマンス上の利点があります。モデルを実行するときには、データセットはソース マップ ドキュメントによってすでに開かれているので、再び開く必要はありません。これにより、パフォーマンスが向上します。
不要な座標変換の回避
詳細については、「ジオプロセシング サービスの空間参照に関する注意事項」をご参照ください。
属性インデックスの追加
タスクが属性検索を使ってデータを選択する場合は、クエリで使用される属性ごとに属性インデックスを作成します。[属性インデックスの追加（Add Attribute Index）] ツールを使用できます。インデックスは 1 回作成すればよく、モデルまたはスクリプトの外で作成します。
空間インデックスの追加
モデルまたはスクリプトがシェープファイルで空間検索を行う場合は、[空間インデックスの追加（Add Spatial Index）] ツールを使用してシェープファイルの空間インデックスを作成します。ジオデータベース フィーチャクラスを使用する場合、空間インデックスは自動的に作成され、管理されます。「空間インデックスの設定」で説明するように、空間インデックスを再計算するとパフォーマンスが向上することがあります。
タスクが使用するデータの事前処理
ジオプロセシング サービスは、Web クライアントによって送信された特定の空間検索に対する答えを提供するためのアプリケーションとして設計されています。タスクは既知のデータの検索であることが多いため、通常は、データを事前に処理することで、検索を最適化することができます。たとえば、属性インデックスや空間インデックスの追加は単純な事前処理の 1 つであり、タスクの外で一度行うだけで済みます。
次に、チュートリアル データで提供されるジオプロセシング サービス サンプルでの事前処理の例をいくつか示します。
- 「GP サービス: 集水域ラスタの作成（Watershed）」では、累積流量および方向ラスタを作成することにより、水文データを事前に処理します。
- 「GP サービス サンプル: データの選択」の Select Tax Lots By Neighborhood (optimized) モデルでは、[インターセクト（Intersect）] ツールを使用してデータを事前に処理します。
- ネットワークでは、[ロケーション フィールドの計算（Calculate Locations）] ツールを使用して、ネットワーク上の固定点の位置を事前に計算します。[ロケーション フィールドの計算（Calculate Locations）] の使用例については、「GP サービス サンプル: 道路ネットワークでの近傍フィーチャの検出」をご参照ください。
データのシェープファイルへの書き出し
シェープファイルへのデータの書き出しは、他の形式への書き出しよりも高速です（メモリにデータを書き出すだけのほうがより高速です）。ただし、10 文字のフィールド名、null 値への非対応、日時サポートの制限など、シェープファイルには厳しい制限がいくつかあります。これらの制限により、モデルまたはスクリプトが機能しなくなる可能性があります。シェープファイル出力の詳細については、「ジオプロセシングでのシェープファイル出力の注意事項」をご参照ください。
データ サイズの削減
データを処理するソフトウェアは、データセットが小さい場合に高速に動作します。地理データのサイズを削減できる方法がいくつかあります。
- [フィールドの削除（Delete Field）] ツールを使用して不要な属性を削除します。
- ライン フィーチャとポリゴン フィーチャには、それらの形状を定義する頂点があります。各頂点は XY 座標です。フィーチャに必要以上の頂点が含まれていて、データセットのサイズを意味もなく増加させていることがあります。
- 外部ソースから受け取ったデータには、重複した頂点が含まれていたり、フィーチャの定義に役立たないほど近接している頂点が含まれていることがあります。
- 頂点の数は解析の縮尺と一致しません。たとえば、大きい縮尺に適した詳細がフィーチャに含まれていて、解析または表示が小さい縮尺で行われることがあります。
非同期モードではなく同期モードの使用
同期とは、サーバがタスクの実行を完了するまでクライアントが待機することを意味します。非同期とは、サーバがタスクを実行している間、クライアントが他の作業を行えることを意味します。同期モードでタスクを実行すると、非同期モードで同じタスクを実行した場合の 10 分の 1 の時間で済みます。