ArcSOCの可用性と利用状況
サービスのArcSOCインスタンスの可用性と利用状況を最適化することは、ユーザーがサイトへの動的リクエストから迅速な応答時間と短い待機時間を得るのに役立つ良い戦略です。また、サービスが決して使用しない多くのインスタンスを実行しないため、メモリなどのサーバーリソースの利用にも利益があります。
しかし、専用サービスのインスタンスの最小数と最大数を最適化することは一度きりの作業ではありません。サービスの使用パターンは時間とともに変化する可能性があるため、この情報を収集する作業はGIS管理者として定期的に見直す必要があります。
ArcSOCインスタンスのアクティビティ統計を観察する方法に入る前に、ArcGIS Serverの2つのArcSOCベースのサービスタイプの重要な詳細と、それらがこの議論にどのように関係しているかを確認しましょう：
注意：待機時間とは、ArcSOCインスタンスが利用可能になり処理を開始するまで、サーバー上の「キュー」でリクエストが費やす時間です。
専用インスタンスプールサービス
Dedicated services（例：ホストされておらず共有されていないサービス）は、多くのアプリケーションがジオプロセシング、Branch Version編集、およびUtility Networkワークフローなどの機能に依存しているため、展開で主要なArcGISリソースです（これらすべては専用サービスを必要とします）。
このようなサービスは非常に多用途であり、その提供する機能性からArcGISの主要な柱ですが、GIS管理者としては、サイトとユーザーが成長するにつれて利用可能なリソースを最大限に活用するために、ArcSOCインスタンス（最小数および最大数）を定期的に調査、調整、および構成する必要があります。
ArcSOCインスタンスについて詳しくは次をご覧ください： サービスインスタンスを理解する
共有インスタンスプールサービスの制限
Shared service instancesは素晴らしいです！有限なリソースで多くのサービスへの需要を管理する管理者にとって真のゲームチェンジャーです。しかし、それらの制限と要件により、どのサービス機能が使用できるかが制限されます。例えば、ジオプロセシング、Branch Version編集、およびUtility Networkは現在共有サービス（またはホストされたサービス）ではサポートされていません。これにより、そのような機能には専用サービスのみが選択肢となります。
設定されたArcSOCインスタンス可用性とインスタンス需要
非常に人気があり重要であるか、または専用サービスタイプで実行する必要があるサービスの場合、最適なインスタンス設定を理解することは重要です。最大アクティブインスタンス数が高すぎると、メモリ（およびコスト）が無駄になります。ArcSOCインスタンスの過剰割り当ては重要ですが独特なケースであり、その影響は応答時間だけの分析では現れません。
逆に最大数が低すぎると、ユーザーが既に忙しいArcSOCインスタンスが空くまで頻繁に待つことになり、パフォーマンス（応答時間増加や待機時間延長）の影響があります。
もちろん、インスタンス最小値と最大値を異なる値に設定するとトレードオフもあります。パフォーマンスが最優先される重要なサービスでは、インスタンス起動中にユーザーリクエストが待機することは時間がかかりパフォーマンスに影響します。したがって、本質的なサービスで予測可能なパフォーマンスを得るには、最小値と最大値を同じ値に設定することを推奨します。
次のサービスインスタンス入門にも記載されています：
したがって、ArcGIS Server管理者はサイトで実行されているインスタンス数を監視し、メモリ使用量によってパフォーマンスが阻害される場合には実行中のインスタンス数を制限することが重要です。
サービスの可用性（インスタンス最小値および最大値による）とユーザー需要によるその設定への影響を構成することは、最適に稼働するサイトには不可欠です。サービス可用性設定（最小・最大インスタンス）と専用サービスへのリクエストへの直接的影響との間には相互関係があります。最適設定を見つける作業は継続的ですが、この課題に取り組むためのツールやリソースもあります。
ArcGIS Server サービスレポート
ArcGIS Server Service Report（10.1で導入）はあまり知られていないREST Admin APIの宝石です。このリソースはフォルダ内すべてのサービスの構成可能な概要を提供し、サイト監視に役立ちます。一般的に高速な応答性能があります（要求されるフォルダ内サービス数によります）。
返されたレスポンス内のinstance service statisticsセクションは非常に価値があります。これは展開全体（例：ArcGIS Serverサイト）でのArcSOCインスタンス（最小・最大・ビジー）の詳細を一覧表示します。
このエンドポイントを定期的にポーリングすることで、その時点で発生しているサービスインスタンス構成と需要とのリアルタイム洞察が得られます。この情報によってマシンおよびサービスリソース最適化についてより良い判断ができ、それによって応答時間改善や待機時間短縮につながります。
注意：ArcGIS Serverでは、 instance service statistics 情報と Statistics ページ（Manager内）は同じデータビューを提供していますが実際には異なるリソースです。サービス統計は生データアクセス（サイト全体および各マシン単位）や詳細情報も提供します。一方Statisticsページはその情報からレポート作成用インターフェイスです。
Soccerによるサービスレポート収集自動化
関心フォルダのService Reportエンドポイントを定期的に監視するスクリプトやプログラムまたはツールなら何でも十分です。ただし無料で既存ツールを探している場合はSoccerがおすすめです。
(Arc)SOC ScannERまたはSoccerは特定ArcGIS Serverフォルダ内サービス統計をスキャンし読み取るユーティリティです。収集したデータを解析しCSVファイルへ書き出して追加分析（例：スプレッドシートでチャート作成し使用状況可視化）できます。これはArcGIS Server REST Admin Service Reportリソースから情報収集しています。Soccerの元々の目的は特定フォルダ内レポートエンドポイント出力取得および各サービスごとのArcSOCインスタンス統計（例：Running, Busy, Maximumなど）保存でした。
現在Soccerはコマンドラインのみ対応ユーティリティです。.NET 6.0ポータブルランタイムでWindows (win-x64)、Linux (linux-x64)、macOS (osx-x64)向けに提供されています。
簡単さからSoccer実行には3つ入力だけ必要です（他パラメータも渡せば機能拡張可能）：
soccer.exe -s "[https://ArcGISServer/ServerWebAdaptor]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"
例えば：
soccer.exe -s "https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."
注意: 事前に生成されたArcGIS ServerトークンはPortalから取得できます。通常、generateTokenのURLは次の通りです:<\/STRONG> https://gisserver.domain.com/portal/sharing/rest/generateToken そしてWebappのURLは次のようになります:<\/FONT> https://gisserver.domain.com/server/admin。有効期限の値は、予想される監視期間に適したものに設定してください。<\/FONT>
コマンドウィンドウから実行中の標準出力:<\/FONT>
接続先: "https://gisserver.domain.com/server " (Gas)<\/FONT>
停止するにはCtrl-Cを2回押してください...<\/FONT>
5秒間スリープ中...<\/FONT>
実行中、soccerは指定されたArcGIS ServerフォルダのService Reportエンドポイントに接続し、データを収集してローカルのCSVファイルに書き込み、その後スリープします。スリープ時間が経過すると、このプロセスを繰り返します。soccerは手動で停止（Ctrl-C）されるまで収集を続けます。<\/P>
注意: ルートArcGIS Serverフォルダで収集するには、-f "/" または -f "" を使用してください。<\/STRONG>
CSVファイルの解析<\/H1>シンプルなテキストビューアで見たサンプル内容:<\/P>DateTime,Epoch,IntervalSeconds,Host,Folder,ServiceName,Type,Provider,Running,Busy,Maximum,Free,NotCreated,Initializing,Transactions,TotalBusyTime,ServicesCollected,ResponseTimeMilliseconds,ContentLength,ConfiguredState,RealTimeState,Message
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,success
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,success
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,117.901,6065,STARTED,STARTED,success
5/2/2023 1:12:50 AM,... (省略) ...
注意: 設計上、IntervalSecondsやResponseTimeMillisecondsなどの列は、観察対象フォルダ内に複数のサービスが存在する場合、重複した値が表示されます。<\/STRONG>収集されたデータは典型的なCSVですが、関心のあるサービスからArcSOCアクティビティを迅速に分析するために役立つ重要なフィールドがあります:<\/P>IntervalSeconds<\/LI>ServiceName<\/LI>Running<\/LI>Busy<\/LI>Maximum<\/LI><\/UL>
CSVファイルをスプレッドシートで開くことで、同じフォルダ内にある他のサービスをServiceName列で簡単にフィルタリングできます。その後、IntervalSeconds、Running、Busy、Maximumの値をプロットして（例：Scatter with Smooth Lineチャートで）インスタンス構成と受信需要を可視化できます。この場合、Gas_Utility_Networkサービスは最小／最大インスタンス構成が32／32に設定されていました。<\/P>
以下は「磨き上げられた」チャートです:<\/P>
注意: MaximumとRunningはそれぞれArcSOCサービス構成インスタンスの最大値と最小値を表します。この場合、Runningは同じ値でMaximumの「背後」にプロットされています。Busyはサイト内すべてのマシンでアクティブだったインスタンス数（ユーザーからのリクエストによる）を示します。<\/FONT>このケースでのチューニングと最適化の「目標」は、Busy値が常にMaximumに達することを避けることです。もしそうなれば、インスタンスが常に忙しくユーザー需要を満たすための十分なArcSOCが利用できなかったことを意味します。その結果、ユーザーリクエストは応答時間や待機時間が増加しやすくなります。リクエストがシステム内で長時間待機するとタイムアウト（通常60秒後）します。多くのサービスリクエストタイムアウトはユーザー体験に悪影響を及ぼします。<\/P>この監視期間からの観察によると、Busy列の値の増減は利用可能な最大インスタンス数には全く近づいていませんでした…これは一面では良いことでした。しかしこれはまた、多数のインスタンスが稼働してメモリを消費しているにもかかわらず使用されていないことを示しており、それは理想的ではありませんでした。<\/P>今後システム資源を最適化するため、このサービスのインスタンス構成は予想されるピーク使用量に近いより低い値（例：18～24あたり）に設定できたでしょう。<\/P>18を使用するとメモリ節約になるが、一部インスタンスでユーザーがリクエスト完了まで長く待つ可能性あり<\/LI>24を使用するとパフォーマンス優先でメモリ使用量増加<\/LI><\/UL>まとめ<\/H1>最小および最大インスタンス数の「最適化」されたサービス設定があっても、ユーザーが遅いパフォーマンスに遭遇しない保証にはなりません。ユーザーのニーズや習慣は時間とともに変化するため、この情報を定期的に監視する必要があります。<\/P>現実には、十分なインスタンスと豊富なシステム資源があっても展開環境でサービス待ち時間が発生する状況があります。サービス待ち時間を完全になくすことは現実的ではなく、それよりも減らすことが実用的です。 サービスインスタンスの最適化は管理者が直接制御できるものであり、待ち時間に影響します。<\/P>専用サービス向けArcSOCインスタンス構成とユーザー需要との関係を理解し定期的に評価することは、GIS管理者がサイトをより良く計画・管理しパフォーマンス最適化と資源効率的利用を支援する鍵となります。<\/P> <\/STRONG> <\/P>
