MapServiceにはいくつのレイヤーを含める必要がありますか-トレードオフは何ですか？

MapServices for ArcGISをセットアップするとき、多くのレイヤーが含まれるmxdがよく表示され、それを公開するように指示されます。

各レイヤーの数が少ないマップサービスを増やすべきですか、それともレイヤー数の多いマップサービスを減らすべきですか？

トレードオフは何ですか？

マップサービスはかなりコストがかかります。それらは、少なくとも1つのArcSOCプロセスが常に実行され、常にメモリを消費していることを必要とします（私のボックスではそれぞれ60〜100 MB-それほど重要ではありません）。Windowsには、多くのプロセスを開始するときに問題となる可能性がある制限付きのデスクトップヒープもあります。クライアントが「マップサービスを追加し続ける」ルートをたどって、サーバーがサポートできる範囲のトップにすぐに到達することを確認することがよくあります。各マップサービスには、独自のデータベース接続も必要になるため、考慮する必要がある場合があります。

単一のサービスにも多数のレイヤーがあると、パフォーマンスが低下することを想定しています。具体的な情報はありませんが、追加のマップサービスほどコストがかかるとは思えません。

サービスを公開するときは、ターゲットオーディエンスとその目的をマップで検討することが常に適切です。彼らは速い地図が必要ですか？正確な地図が必要ですか？かわいい？彼らは物事を邪魔にならないようにスワイプしたいですか？彼らはそれをいたずら書きするのでしょうか？

レイヤーに複数の異なるデータソースがある場合、類似したデータソース（まったく同じ、または同じ投影、または同じ平均速度）からのレイヤーをグループ化するとうまく機能します。次に、マップ画像全体を取得するために最も遅いレイヤーがロードされるのを待ちません。

ユーザーに一連のレイヤーに対する特定のビジネスニーズがある可能性がある場合は、サービスをオフにしたり、フェードアウトしたりできると便利です。サーバー上でそのようにペイントするよりも、クライアント上でマップ画像全体を50％の透明度で描画する方がはるかに簡単です。

ラベル付けとレンダリングが非常に重要である場合、より多くのレイヤーを備えたより少ないサービスを使用すると、おそらくよりうまく機能します。複数のサービスが独自のラベルをレンダリングしてから一緒に合成すると、ArcGIS Serverは各ラベルが異なるサービスに配置される場所を「計画」できないため、多数のレイヤーを持つ単一のサービスよりもラベルの衝突が発生します。

同様に、半透明のポリゴンを扱う場合、特にJPEG圧縮が役立つ写真レイヤーを使用して描画している場合は、それらをすべて1つのサービスに統合すると、画像の合成に適しています。

可能な限りfcをサブタイプにグループ化して、サーバーの過負荷を軽減し、マップサービスで維持するfcの数を減らす機会を提供します。