1つまたは複数のサービスに多数のレイヤーがありますか？（なぜ）

どうすればいいか迷っている。したがって、idは、正当な回答を得るためにGIS-SEに配置するのが好きです。

シナリオ：

• クライアントにはWebマッピングアプリケーションがあります。複数の小さなアプリケーションに分割する必要はありません。 これは、現代のアプローチがWeb上のマップ（つまり、1つのメインWebマップ上に焦点を絞った多くのWebマップアプリ）に反するものの、一部のユーザーにとって、GISアプリケーションをWeb上で複製しようとすることは、わかりました（時々）。

• クライアントは、ベースマップレイヤーの多くを個別のサービスにキャッシュしました。

• クライアントは、ダイナミックマップサービスにさらに600〜700のレイヤーを追加する必要があります...
• サービスは、これらのすべてのレイヤーをオフにして公開されます。
• ユーザーが一度に10〜40を超えるレイヤーをオンにすることは想定されていません。

これに対するあなたの最初の反応は私のものと似ていると思います（600+ ?! WTF ?!）

ただし、要件は明確に設定されていますが、それはなぜですか？以前のArcIMSアプリケーションには同様の機能がありましたが、この新しいArcGIS Server製品で同じことができないのはなぜですか？ユーザーは、レイヤーが他の部門に属している場合でも、レイヤーの範囲全体で相互比較および分析を実行できる必要があります。

結論に進む前に、クライアントはArcGIS Serverの管理者です。
彼らは、すべてのベストプラクティスルールによって600層を管理しています。たとえば、定義クエリと組み合わせた縮尺範囲; ラベル上の注釈。小規模で複雑なレイヤーを一般化する。MSDとして公開します。等

問題点：

ここでより良いアプローチは何ですか？

1. 600のレイヤーすべてを1つのダイナミックマップサービスに公開します

2. レイヤーを論理グループ（水文学、計画、生態学、ユーティリティなど）に分割します。

＃1を使用し、いくつかの複雑なレイヤーがオンになっている場合。単純なポイントレイヤーをオンにしたい場合、ArcGIS Serverは表示されているレイヤー全体を再度レンダリングする必要があります。

＃2を使用する場合、リクエストを行うたびに、Webアプリケーションは個々のマップサービスからExportMapsに対して複数のGETリクエストを行う必要がある可能性があります（これは悪いか、＃1経由でArcGIS Serverに追加の負荷を作成します） ？）

そして、これにより、すべてが可能な限り高速になるように構成とチューニングが行われます。ArcGIS Serverのバックエンドを複数のホストに拡張し、適切なハードウェアを配置できます。

＃1を使用すると、AGSが処理できるインスタンスの最大数をスローできます。

＃2に進むと、マップサービスのパフォーマンスを評価し（負荷テストと待機時間を確認）、それに応じてmin / maxインスタンスに対処し、「弱いリンク」であるサービスが1つもないことを確認します。

私は現在、＃2のアプローチに傾いています。私のサービスでは、1つのサービスに600のレイヤーがあることは狂気だとまだ言っていますが、デフォルトですべてオフにされている場合、問題はありません。

あなたの考えを聞いてみたいです。コメントを使用して詳細情報が必要な場合はお知らせください。ただし、「デスクトップアプリケーションを使用する」や「別の方法でそれらを教育する」などの回答は求めません。

コメントでの議論から、私は別の考慮事項について言及しなかった。サービスが使用されるアプリケーションには、レイヤーレベルのセキュリティ（アプリケーションレベル）の機能があります。したがって、ユーザーのグループ（かなり大きい）は特定のロールに割り当てられ、そのロールは600のレイヤー全体にアクセスできます。他の役割は制限されます。

キャパシティプランニングツールを使用して、1つの超ヘビーマップサービスと4つのライトマップサービスを比較しました。結果は、ヘビーマップサービスが最適な方法であることを示しています。

これは正しい答えではない可能性があり、キャパシティプランニングツールはすべての要素（ユーザーワークフローなど）を考慮していません。コメントでご意見をお聞かせください。

1つの非常に重いマップサービス：
アプリサーバーのCPU使用率= 49.4％
データベースサーバーのCPU使用率= 7.6％
ネットワーク負荷= 16 Mbps
ディスプレイ応答時間= 0.88秒

（RCで画像を大きく表示し、新しいタブで開くことができます）

4つのliteのマップサービス：
アプリケーションサーバーのCPU使用率= 55.4パーセントの
データベース・サーバーのCPU使用率= 7.6％
ネットワーク負荷= 64 Mbpsのは、
Webブラウザのオーバーヘッドに応じて、0.32と1.28秒の間ので、応答時間= 0.32秒毎の表示します

1つのマップサービスアプローチをサポートするための追加ロジック：

1. したがって、すべてのレイヤーは同じマップサービスにあります。
   a。1つの要求がサーバーに送信されます
   b。1つのSOCプロセスがマップを描画します
   c。1つの画像がネットワーク経由で返されます

2. したがって、40のレイヤーは4つのマップサービスに分散しています（各10レイヤー）。
   a。4つのリクエストがサーバーに送信されます
   b。4 SOCプロセスがマップを描画します
   c。4つの画像がネットワーク経由で返されます

1aおよび1cは、2aおよび2cよりも高速で、ネットワークへの負荷が少なくなります。

2bは、並列処理を使用して1人のユーザーに対して1bよりも速いマップを返すことができますが、これは多くのユーザーには当てはまりません。実際、2bのサーバーによって処理される追加のトランザクションのオーバーヘッド（および2cの追加のネットワーク負荷）は、ユーザーの数が増えるにつれて1bのスケールがはるかに良くなります。

複数のサービスの使用、レイヤー/ラベルのスケーリング、キャッシュ、および非動的ラベルの使用はすべてWebアプリケーションエクスペリエンスの向上に役立ちますが、600以上のすべてのレイヤーを1つのアプリケーションにロードする最初のヒットはエンドユーザーに顕著になります。特に、TOCの設定にかかる時間。600+層のアプリケーションを作成する必要がある場合、私は間違いなくオプション2を使用します。あなたはに対してあなたのデータカルコゲノフルバレン骨格をモデル化することが、データモデル（たとえば、地方政府のデータモデルなど）。

以下のホワイトペーパーでは、ArcGIS Server Webアプリケーション構成の興味深いベストプラクティスガイドラインとパフォーマンス統計をいくつか取り上げています。

http://www.esri.com/library/whitepapers/pdfs/creating-arcgisserver-web-mapping.pdf