Skip To Content

ベスト プラクティスを使用したサービスのチューニング

ArcGIS 11.4 (Linux)  | |  ヘルプのアーカイブ

ArcGIS Server 管理者は、時として、パフォーマンスに関してサイト内のサービスを最適化し、待ち時間を減らして、サービスのダウン タイムをなくす方法を決定する必要に迫られることがあります。

たとえば、特定のサービスを表示するのに異常なほど、または容認できないほどの待ち時間を要していることをユーザーが電話で連絡してきた場合や、 一般的な Web アプリケーションで使用されているサービスの 1 つまたはサービスのセットについて、これから数日中に使用頻度が大幅に増えると予想されている場合を考えてみます。 この種の問題が発生したときに備えて準備し、問題を緩和するために最も適した方法とは何でしょうか。 以下で示すベスト プラクティスを規則的に実践すれば、サイトの効率とパフォーマンスをユーザーのために向上させることができます。

このチュートリアルでは、ArcGIS Server サイトで発生する一般的シナリオを重点的に取り上げ、それぞれのシナリオに対処するためのトラブルシューティング手順とベスト プラクティスを推奨します。

ArcGIS Server Manager ログを使用したサービスのパフォーマンスの監視

サイトに関する問題がどこに存在するかを明らかにする最も効果的な方法の 1 つは、ArcGIS Server Manager ログを使用して、イベントを監視し、潜在的エラーを特定して、問題のトラブルシューティングを実行することです。 サーバー ログを使用すると、次のようなイベントをキャプチャ、クエリ、表示できます。

  • レイヤーの描画時間
  • サービスの使用状況
  • 停止されたサービス

Server Manager ログがサービスに関する問題の特定にどのように役立つかを示すために、次のシナリオおよびその考えられる原因と解決策を考察してみます。

シナリオ

組織内のユーザーから、特定のマップ サービスで許容できないほどの表示時間がかかっているとの連絡を受けました。 マップ サービスについてテストを実施した後、そのマップ サービス内にある特定のレイヤーの描画時間が長いことが判明します。 さらに調査を進めるために、サーバー ログを使用してマップ サービスのパフォーマンスのトラブルシューティングを実行し、このマップ サービスに関連する情報を切り分けます。

考えられる原因 1

Server Manager ログを確認したときに、サービス内の 1 つまたは複数のレイヤーの描画時間が過度に長いことが判明します。

原因 1 の一般的解決策

次のベスト プラクティスを使用して、パフォーマンスに関してマップを最適化します。

  • 縮尺依存のレンダリングの利用。
  • 使われていないレイヤーとデータ フレームの削除。
  • フィルター設定の検証の使用。
  • レイヤーのシンボルの単純化
  • 可能な場合 (データの変更頻度が少ない場合など)、キャッシュ マップの使用を検討。
  • 詳細については、「キャッシュされていないマップのパフォーマンスに関するヒント」をご参照ください。

サービスを確認して、最適化のためのヒントを実装し、サービスを再公開すると、当該マップ サービスの応答性が大幅に向上しているのがわかります。

考えられる原因 2

Server Manager ログに、サービス内のレイヤーへのネットワーク アクセスの遅延がサービスのパフォーマンスを低下させている可能性があることが示されます。

原因 2 の一般的解決策

データ アクセスおよび管理のための次のベスト プラクティスを使用して、ネットワークの遅延を最小限に抑え、サービスのパフォーマンスを最適化します。

サービスを確認して、データ アクセスおよび管理のためのヒントを実装し、サービスを再公開すると、当該マップ サービスの応答性が大幅に向上しているのがわかります。

ArcGIS Server 統計情報を使用したサービスのアクティビティの監視

サーバー統計情報は、サイトでサービスのアクティビティを監視するためのもう 1 つの有益な手段です。これらの情報は Server Manager[ログ] タブにあります。 サーバー統計情報には、次のような、サービスのアクティビティについての概要が示されます。

  • 自分のサイトで先週中に処理されたリクエストの総数は?
  • 時間単位でのサービスのパフォーマンスは?
  • 任意の時点で特定のサービスに使用されたサービス インスタンスの最大数は?

ArcGIS Server 統計情報がサービスのリソースの効率的な割り当てにどのように役立つかを示すために、次のシナリオおよびその考えられる原因と解決策を考察してみます。

シナリオ

非常に評判の良い Web アプリを作成したので、公表された今週末の日付にそのアプリを幅広い利用者に公開しようと考えています。 このアプリのサービスに対して大量のリクエストが送られると予測されるため、この使用状況に対応できる十分なコンピューター リソースを確保できるようにする必要があります。

この Web アプリの高い利用率に対応できる十分なサーバー コンピューター リソースを割り当てるには、ArcGIS Server 統計情報を確認して、ほとんど使用されないサービスを特定し、このアプリの利用者に対処できるようにそれらのサービス プロパティを適宜調整します。 同様に、この Web アプリで使用されるサービスについても、サービス プロパティを適宜調整します。

考えられる解決策

サイト用のリソースを割り当てるサービス プロパティを管理して微調整します。 たとえば、ユーザーがサービスを使用する時間の長さを検討します。 サービスが、その最大使用時間を超えて使用されていますか? サービスに対するリクエストが過剰なため、エンド ユーザーがタイムアウトになっていますか?

次の推奨事項をガイドとして使用して、エンド ユーザー数を予測および対処できるようにサービス プロパティを調整します。

  • 最もよく使用されるサービスを特定して、サービスごとの最小インスタンス数を低減します。 これを行うと、エンド ユーザーの待ち時間が減少します。
  • 最も使用頻度の低いサービスを特定して、最小インスタンス数を 0 に変更します。 この設定は、より使用率の高い他のサービス用にリソースを解放する際に役立ちます。
  • エンド ユーザーのために遅延を緩和できるように、必要に応じて最小および最大インスタンス数、待ち時間、アイドル時間、使用時間を増加させます。
  • システム リソースを最も必要とするサービス用にそれらのリソースを解放できるように、必要に応じてインスタンス数、待ち時間、アイドル時間を減少させます。

サービスのリソースとサイトの管理についての追加情報

  • ダイナミック マップを使用する際は、ホスト フィーチャ レイヤーを追加した際にマップのパフォーマンスに与える影響を検討します。 たとえば、マップに含まれるホスト フィーチャ レイヤーが 100 以上になると、マップのパフォーマンスに影響が出る可能性が高くなります。
  • 可能であれば、ダイナミック マップ サービスではなく、キャッシュ (タイル) マップ サービスを使用します。 詳細については、「マップ キャッシュとは」をご参照ください。
  • エンタープライス データとローカル データなど、データ格納に関する推奨事項を検討します。 詳細については、「ArcGIS Server サイトでのデータ格納の検討事項」をご参照ください。
  • サービスのチューニングと構成に関する推奨事項を検討します。
  • サービス プロパティの調整によるユーザー数への対処に関する推奨事項を検討します。