共有サービスインスタンスプール
ArcGIS Enterprise サイトのロードテストについて話すとき、通常は専用またはホストされたフィーチャ サービスの消費に関する会話が行われます。
長年にわたり、専用およびホストされたサービスは、高トラフィックのマップリソースをオンラインで迅速かつ信頼性の高い方法で消費する手段を提供してきました。これは変わっていません。
しかし、ユーザーにマップを提供する別のタイプのリソースがあります：共有サービスインスタンスプールです。
10.7で導入された共有インスタンスプールは、システムメモリ使用量がパフォーマンスより優先される場合でも、依然として価値のあるサービスを表示およびクエリしやすくします。
この機能は、高いサービス密度の公開（例：多くの実行中サービスを公開可能）を可能にしますが、一部の速度とスループットを犠牲にします。多くの組織にとって、一般的に専用またはホストされたサービスよりも共有サービス候補が多いため、これは良いトレードオフとなり得ます。
この有利な特性から、共有サービスは真のゲームチェンジャーとなりました。しかし、ロードテストの観点からはいくつか考慮すべき点があります。
注意：GIS管理者として、すべての共有サービスは互いに同等の価値を持つと仮定してください。また、dedicated services は shared services よりも優先されるべきであると仮定してください。
共有サービスはロードテストすべきか？
これが$64,000の質問です！パフォーマンスアナリストとして、この質問はサイトにサービスを公開するときによく出てくるかもしれません。
共有サービスのスケーラビリティプロファイルを理解するためにロードテストしたくなることは非常に魅力的ですが、この戦略が*適切でない*理由はいくつかあります：
- スケーラビリティが最重要なら、そのサービスは dedicated に移動すべきです
- 共有サービスもスケール可能（例：同じアイテムへの複数同時リクエストをサポート）ですが、それが主な機能ではありません
- 管理者は既にメモリ使用優先でサービスを指定しています
- サービスを shared として構成することで、そのサービスが頻繁に要求されないことが期待されています
- サービスが時折遅いまたはやや遅い応答時間になる場合でも、それは問題ありません
- そのようなサービスをテストすると専用サービスからハードウェアリソースを奪います
- dedicated services は「ファーストクラス」サービスなので、shared services と競合させないでください
- dedicated および hosted services はスケーラビリティのための主要な手段です
- shared services はそうではありません
- shared services をテストまたは頻繁にリクエスト送信すると、CPUやメモリなど（限られた）システムリソースが高速パフォーマンス提供に必要なサービスから奪われる可能性があります
- テスト計画管理上の課題
- サイトには数十または数百もの共有サービスが存在することが珍しくありません
- すべての共有サービスが同等と仮定すると、100以上の共有サービスを効果的にテストおよびプロファイリングするテスト計画は困難で管理が大変になる可能性があります
サイトに shared と dedicated の混在したサービスがある場合、dedicated サービスはまだテストできますか？
はい。dedicated サービスのパフォーマンスとスケーラビリティプロファイルを理解することは、サイトを最適に展開および管理するために依然として価値ある情報です。dedicated サービスは通常通りテストしてください。
それが唯一公開されているインスタンスプールタイプの場合、shared services はテストできますか？
shared services のロードテストを妨げる技術的制限はありません。
そのようなテストを実行することは確かに可能ですが、上記の理由から推奨されません。
サイトを定期的に分析および監視する
サービスの人気度は時間とともに増減します。定期的にサービス要求のトラフィックパターンを分析することで、管理者はサイトを最適に構成および管理するための情報を得ることができます。これは、一部のサービスへの要求頻度が増加した場合（または増加すると予想される場合）、それらを手動で shared service から dedicated service に移行できることを意味します。
