ジオプロセシング サービスのパフォーマンスのヒント

クライアントは高速なサービスを期待しているため、ジオプロセシング サービスは高速かつ効率的である必要があります。ArcGIS for Server は一度に複数のクライアントに対処できるため、効率の悪いサービスによってサーバが過負荷状態になる可能性があります。サービスの効率がよいほど、同じコンピュータ リソースを使って対処できるクライアントの数が増えます。

次に、サービスのパフォーマンスを向上させるためのヒントと手法を示します。ここでは、これらの手法をパフォーマンスの向上率が高いものから順に示します。最後に示すいくつかのヒントは実行時間を何秒か短縮することができます。一部のタスクでは、それが必要になるかもしれません。

プロジェクト データでのレイヤの使用

ジオプロセシング ツールを実行して結果を作成し、それを公開するときに、ディスク上のデータセットへのパスではなく、レイヤを入力として使用して、ツールを実行する必要があります。レイヤはディスク上のデータセットを参照し、データセットに関するプロパティをキャッシュします。これは特に、ネットワーク データセット レイヤおよびラスタ レイヤの場合に当てはまります。データセットへのパスの代わりにレイヤを使用すると、パフォーマンス上の利点があります。これは、サービスが、開始時にデータセットからレイヤを作成し、データセットの基本プロパティをキャッシュし、データセットを開いたままにするためです。サービスを実行すると、データセットのプロパティが即座に使用可能になり、データセットが開いて動作可能になって、パフォーマンスが向上します。

たとえば、Esri サンプル サーバおよび ArcGIS Network Analyst エクステンションの可視領域サービス、走行時間ポリゴンを作成する例は、すべてレイヤを利用していますデータセットのサイズに応じて、サービス実行時間を 1 回あたり 1 〜 2 秒以上短縮できます。

ArcGIS Server に対してローカルなデータの使用

ジオプロセシング サービスで必要なプロジェクト データは、ArcGIS Server に対してローカルである必要があります。ネットワーク共有(UNC)を介して共有され、アクセスされるデータは、同じコンピュータ上で使用可能な場合に比べて低速です。パフォーマンスを示す数字はさまざまですが、LAN 経由でデータを読み書きすると、ローカル ディスクの場合に比べて 2 倍の時間がかかることがよくあります。

中間データのメモリへの書き込み

中間(テンポラリ)データはメモリに書き込むことができます。データをメモリに書き込むほうが、ディスクに書き込むよりも高速です。

注意注意:

結果マップ サービスを使用している場合を除き、出力データもメモリに書き込むことができます。

新たにバージョン 10.1 では、ラスタをメモリに書き込むことができます。

データのメモリへの書き込みの詳細

タスクが使用するデータの事前処理

ほとんどのジオプロセシング サービスは、Web クライアントによって送信された特定の空間検索に対する答えを提供するためのアプリケーションとして設計されています。タスクは既知のデータに対する特定の操作であることが多いため、通常は、データを前処理することで、操作を最適化できます。たとえば、属性インデックスまたは空間インデックスの追加は、空間または属性の選択操作を最適化する簡単な前処理です。その他の例:

属性インデックスの追加

タスクが属性検索を使ってデータを選択する場合は、クエリで使用される属性ごとに属性インデックスを作成します。[属性インデックスの追加(Add Attribute Index)] ツールを使用できます。インデックスは 1 回作成すればよく、モデルまたはスクリプトの外で作成します。

空間インデックスの追加

モデルまたはスクリプトがシェープファイルで空間検索を行う場合は、[空間インデックスの追加(Add Spatial Index)] ツールを使用してシェープファイルの空間インデックスを作成します。ジオデータベース フィーチャクラスを使用する場合、空間インデックスは自動的に作成され、管理されます。「空間インデックスの設定」で説明するように、空間インデックスを再計算するとパフォーマンスが向上することがあります。

非同期モードではなく同期モードの使用

ジオプロセシング サービスを同期または非同期のモードで実行することを指定できます。非同期モードでは、極わずかなオーバーヘッドがサーバで発生します。つまり、非同期タスクが 1 秒未満で実行さることはほとんどありません。同期モードでタスクを実行すると、非同期モードで同じタスクを実行した場合の 10 分の 1 の時間で済みます。

不要な座標変換の回避

タスクが、座標系が異なるデータセットを使用する場合、タスクが使用するジオプロセシング ツールによって、実行時にそれらの座標を 1 つの共通の座標系に変換する必要があることがあります。データセットのサイズによっては、座標を 1 つの座標系から別の座標系に変換するときに、タスクの処理速度が低下する場合があります。データセットの座標系と、タスクで使用されるツールが座標変換の実行を必要としているかどうかについて、知っておく必要があります。タスクで使用されるすべてのデータセットを 1 つの座標系に変換することをお勧めします。座標系と、それらがジオプロセシング ツールに与える影響について詳しくは、以下のトピックをご参照ください。

データ サイズの削減

データを処理するソフトウェアは、データセットが小さい場合に高速に動作します。地理データのサイズを削減できる方法がいくつかあります。

10.0 とそれ以降のバージョンの相違点

10.0 でジオプロセシング サービスを作成した場合にサービスのオーサリングに便利な特定のパフォーマンス テクニックを以下に紹介します。バージョン 10.1 以降では、これらの技術を使用する必要がなくなりました。

レガシーレガシー:

10.1 より前は、ArcGIS Server を複数のコンピュータで構成するか、arcgisjobs ディレクトリへの UNC パスを使用する場合、ローカル ジョブ ディレクトリを設定することが推奨されていました。各タスクの処理がローカル サーバ上で実行されて最終的にその結果がクライアントに転送される際の実行時間が、このローカル ジョブ ディレクトリによって大きく改善されました。10.1 以降では、ローカル ジョブ ディレクトリを設定するのは GIS サーバ管理者です。しかし、タスク作成者は、タスクでローカル ジョブ ディレクトリを使用することを指定する必要がなくなりました。サーバが複数のコンピュータから成るクラスタに属しているか、UNC パスを使用してディレクトリが参照される場合、自動的にローカル ジョブ ディレクトリが使用されるためです。

レガシーレガシー:

10.1 より前は、ジオプロセシング サービスでラスタを操作する場合、それらを GRID 形式で保持することが推奨されていました。一部のツールが GRID の処理に対して最適化されていたため、通常は GRID 形式がより高速でした。10.1 以降では、すべてのラスタ ツールが、パフォーマンスを低下させることなくソースの形式を読み書きできるようになりました。

関連トピック

5/10/2014