Number of layers in a service
I'm wondering if anyone knows the upper limit on the number of layers in a service? At what point, if any, do you start to see slowing or other problems?
I'm finding folks want the same layers on different Layer Themes, but want them to look different, or have a different configuration. How much should I fight this, or is it not really a problem?
-
As a further question, is it better to break up services into smaller services, or is it better to have fewer services with more layers?
0 -
Mike Hargreaves
Last time I talked to Support they were saying the site maximum is around 700 layers, I had 810 layers in one of our sites. The SL viewer that consumes the site took about 22 seconds to display and has 31 Map Themes. The site has 9 cached map services and I removed all the layers from the site.xml for the cached map services, number of layers was reduced to around 500. The display time went from 22 seconds to 11 seconds. Then we upgraded to GE 3.14 and Silverlight 1.9 and the maps that had the cached layers would not print. I had to add at least 1 layer for maps to print.
One of the dynamic services has about 200 layers in it. What I have experienced with this is my list is long and the map service is off by default for some Map Themes and if the user expands the Dynamic map service and scrolls down to turn on the layer or group they want, sometimes they forget to turn on the Map service itself.
Jimmy Brink
0 -
Thanks Jimmy,
I won't worry so much aboutthe number of my layers, since I'm no where near what you've got! Have you experimented with have more smaller services compared to fewer large services in terms of performance?
0 -
Hi Mike,
Something to keep in mind about the map services is, depending on how they are configured, you're adding at least a couple of ArcSOC processes per service to your server load. That's regardless of whether the service is being accessed or not. Having too many processes running will affect performance, too.
In my experience, fewer services with more layers per service performs better overall.
Steve
0 -
Thanks Steve,
Yes, that was my thinking as well, but wanted to get confirmation. Currently I have just one large dynamic service for our City site and a number of cached services. But now that GC/SL deals better with problem services, I was wondering if it might make sense to break up my dynamic service by functional area, so that if an editor changes something that caused a problem for a service, only their service would be affected. Likewise, if I change the service and republish and something goes wrong, I'm less likely to bring down the whole site. That was happening a lot, but I'm hoping now that I installed SP1 for AGS that will stop...
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
5 Kommentare