ジオプロセシング サービスのパフォーマンスのヒント
このトピックの内容
- プロジェクト データでのレイヤーの使用
- ArcGIS Server に対してローカルなデータの使用
- 中間データのメモリへの書き込み
- タスクが使用するデータの事前処理
- 属性インデックスの追加
- 空間インデックスの追加
- 非同期モードではなく同期モードの使用
- 不要な座標変換の回避
- データ サイズの削減
- 10.0 とそれ以降のバージョンの相違点
クライアントは高速なサービスを期待しているため、ジオプロセシング サービスは高速かつ効率的である必要があります。ArcGIS for Server は一度に複数のクライアントに対処できるため、効率の悪いサービスによってサーバーが過負荷状態になる可能性があります。サービスの効率がよいほど、同じコンピューター リソースを使って対処できるクライアントの数が増えます。
次に、サービスのパフォーマンスを向上させるためのヒントと手法を示します。ここでは、これらの手法をパフォーマンスの向上率が高いものから順に示します。最後に示すいくつかのヒントは実行時間を何秒か短縮することができます。一部のタスクでは、それが必要になるかもしれません。
プロジェクト データでのレイヤーの使用
ジオプロセシング ツールを実行して結果を作成し、それを公開するときに、ディスク上のデータセットへのパスではなく、レイヤーを入力として使用して、ツールを実行する必要があります。レイヤーはディスク上のデータセットを参照し、データセットに関するプロパティをキャッシュします。これは特に、ネットワーク データセット レイヤーおよびラスター レイヤーの場合に当てはまります。データセットへのパスの代わりにレイヤーを使用すると、パフォーマンス上の利点があります。これは、サービスが、開始時にデータセットからレイヤーを作成し、データセットの基本プロパティをキャッシュし、データセットを開いたままにするためです。サービスを実行すると、データセットのプロパティが即座に使用可能になり、データセットが開いて動作可能になって、パフォーマンスが向上します。
たとえば、Esri サンプル サーバーおよび ArcGIS Network Analyst エクステンションの可視領域サービス、走行時間ポリゴンを作成する例は、すべてレイヤーを利用していますデータセットのサイズに応じて、サービス実行時間を 1 回あたり 1 〜 2 秒以上短縮できます。
ArcGIS Server に対してローカルなデータの使用
ジオプロセシング サービスで必要なプロジェクト データは、ArcGIS Server に対してローカルである必要があります。ネットワーク共有 (UNC) を介して共有され、アクセスされるデータは、同じコンピューター上で使用可能な場合に比べて低速です。パフォーマンスを示す数字はさまざまですが、LAN 経由でデータを読み書きすると、ローカル ディスクの場合に比べて 2 倍の時間がかかることがよくあります。
中間データのメモリへの書き込み
中間 (テンポラリ) データはメモリに書き込むことができます。データをメモリに書き込むほうが、ディスクに書き込むよりも高速です。
注意:
結果マップ サービスを使用している場合を除き、出力データもメモリに書き込むことができます。
タスクが使用するデータの事前処理
ほとんどのジオプロセシング サービスは、Web クライアントによって送信された特定の空間検索に対する答えを提供するためのアプリケーションとして設計されています。タスクは既知のデータに対する特定の操作であることが多いため、通常は、データを前処理することで、操作を最適化できます。たとえば、属性インデックスまたは空間インデックスの追加は、空間または属性の選択操作を最適化する簡単な前処理です。その他の例:
- 「ジオプロセシング サービスの例: 集水域ラスターの作成 (Watershed)」のチュートリアルでは、累積流量および方向ラスターを作成することにより、水文データを前処理します。
- [最近接 (Near)] ツールまたは[近接情報テーブルの生成 (Generate Near Table)] ツールを使用して、既知の場所からの距離を事前に計算できます。たとえば、サービスでクライアントが、ロサンゼルス リバーからユーザー定義の距離にある空の土地区画を選択できるとします。[空間検索 (Select Layer By Location)] ツールを使用してこの選択を実行することもできますが、それよりも、ロサンゼルス リバーからのすべての土地区画の距離を ([最近接 (Near)] ツールを使用して) 事前に計算し、その計算済みの距離を土地区画の属性として保存した方が、非常に高速です。[属性インデックスの追加 (Add Attribute Index)] ツールを使用して、この属性にインデックスを追加できます。これにより、クライアントが検索するときに、タスクは効率の低い空間検索を使用するよりも簡単で高速な距離属性の選択を実行できます。
属性インデックスの追加
タスクが属性検索を使ってデータを選択する場合は、クエリで使用される属性ごとに属性インデックスを作成します。[属性インデックスの追加 (Add Attribute Index)] ツールを使用できます。インデックスは 1 回作成すればよく、モデルまたはスクリプトの外で作成します。
空間インデックスの追加
モデルまたはスクリプトがシェープファイルで空間検索を行う場合は、[空間インデックスの追加 (Add Spatial Index)] ツールを使用してシェープファイルの空間インデックスを作成します。ジオデータベース フィーチャクラスを使用する場合、空間インデックスは自動的に作成され、管理されます。「空間インデックスの設定」で説明するように、空間インデックスを再計算するとパフォーマンスが向上することがあります。
非同期モードではなく同期モードの使用
ジオプロセシング サービスを同期または非同期のモードで実行することを指定できます。非同期モードでは、極わずかなオーバーヘッドがサーバーで発生します。つまり、非同期タスクが 1 秒未満で実行さることはほとんどありません。同期モードでタスクを実行すると、非同期モードで同じタスクを実行した場合の 10 分の 1 の時間で済みます。
不要な座標変換の回避
タスクが、座標系が異なるデータセットを使用する場合、タスクが使用するジオプロセシング ツールによって、実行時にそれらの座標を 1 つの共通の座標系に変換する必要があることがあります。データセットのサイズによっては、座標を 1 つの座標系から別の座標系に変換するときに、タスクの処理速度が低下する場合があります。データセットの座標系と、タスクで使用されるツールが座標変換の実行を必要としているかどうかについて、知っておく必要があります。タスクで使用されるすべてのデータセットを 1 つの座標系に変換することをお勧めします。座標系と、それらがジオプロセシング ツールに与える影響について詳しくは、以下のトピックをご参照ください。
データ サイズの削減
データを処理するソフトウェアは、データセットが小さい場合に高速に動作します。地理データのサイズを削減できる方法がいくつかあります。
- [フィールドの削除 (Delete Field)] ツールを使用して、プロジェクト データの不要な属性を削除します。
- ライン フィーチャとポリゴン フィーチャには、それらの形状を定義する頂点があります。各頂点は X、Y 座標です。フィーチャに必要以上の頂点が含まれていて、データセットのサイズを意味もなく増加させていることがあります。
- 外部ソースから受け取ったデータには、重複した頂点が含まれたり、フィーチャの定義に役立たないほど近接している頂点が含まれていることがあります。
- 頂点の数は解析の縮尺と一致しません。たとえば、大きい縮尺に適した詳細がフィーチャに含まれていて、解析または表示が小さい縮尺で行われることがあります。
10.0 とそれ以降のバージョンの相違点
10.0 でジオプロセシング サービスを作成した場合にサービスのオーサリングに便利な特定のパフォーマンス テクニックを以下に紹介します。バージョン 10.1 以降では、これらの技術を使用する必要がなくなりました。
レガシー:
10.1 より前は、ArcGIS Server を複数のコンピューターで構成するか、arcgisjobs ディレクトリへの UNC パスを使用する場合、ローカル ジョブ ディレクトリを設定することが推奨されていました。各タスクの処理がローカル サーバー上で実行されて最終的にその結果がクライアントに転送される際の実行時間が、このローカル ジョブ ディレクトリによって大きく改善されました。10.1 以降では、ローカル ジョブ ディレクトリを設定するのは GIS サーバー管理者です。しかし、タスク作成者は、タスクでローカル ジョブ ディレクトリを使用することを指定する必要がなくなりました。サーバーが複数のコンピューターから成るクラスターに属しているか、UNC パスを使用してディレクトリが参照される場合、自動的にローカル ジョブ ディレクトリが使用されるためです。
レガシー:
10.1 より前は、ジオプロセシング サービスでラスターを操作する場合、それらを GRID 形式で保持することが推奨されていました。一部のツールが GRID の処理に対して最適化されていたため、通常は GRID 形式がより高速でした。10.1 以降では、すべてのラスター ツールが、パフォーマンスを低下させることなくソースの形式を読み書きできるようになりました。