I have a conundrum that I am getting mixed advice on how to go about. Therefore id like to put it to GIS-SE for some justified answers.


  • Client has a web mapping application. Does not want to split into multiple smaller applications. Although this goes against what the modern day approach is for maps on the web, (i.e. lots of focussed web-map apps over one main web-map) I strongly believe that for some users, trying to replicate a GIS application on the web is ok (sometimes).

  • Client has cached as much of his basemap layers into separate services.

  • Client still requires an additional 600-700 layers in a dynamic map service...
  • The service will be published with all of these layers turned off.
  • It is not anticipated that users will turn on more than 10-40 layers at a time.

I imagine your initial reaction to this is similar to mine (600+?! WTF?!)

However - the requirement is set in stone and why not? Their prior ArcIMS application had similar functionality, so why can't this newer ArcGIS Server product do the same? The users potentially need to be able to cross compare and perform analysis on the entire range of layers, even if the layers belong to other departments.

Before you jump to conclusions, the client is a clued up ArcGIS Server admin.
They have administered the 600 layers by all of the best practice rules: e.g. scale ranges combined with definition queries; annotation over labelling; generalising complex layers at small scales; publish as MSDs; etc


What is the better approach here?

  1. Publish all 600 layers into one dynamic map service

  2. Split the layers into logical groupings (hydrology, planning, ecology, utilities, etc)

If you go with #1, and you have a few complex layers turned on. If you want to turn on a simple points layer, then ArcGIS Server will still have to render the entire layers being displayed all over again.

If you go with #2, each time your making a request, potentially, the web application could have to make several GET requests for ExportMaps from the individual map services (is this bad, or does it create additional load to ArcGIS Server over #1?)

And then this leads to configuration & tuning to ensure everything is as quick as possible. We can scale the back end of ArcGIS Server to multiple hosts and have some good hardware to sit it on.

If you go with #1, you can throw the maximum # of instances that you AGS can handle.

If you go with #2, I assume you evaluate the performance of the map services (load testing and look at wait times) and address the min/max instances accordingly to ensure there is not one service that is a 'weak link'.

Im currently leaning towards the #2 approach, as my head is still telling me that having 600 layers in one service is madness, but if they are all turned off by default, there really is no issue.

Would love to hear your thoughts. Let me know if you need more info via the comments, but not looking for answers like 'use a desktop application' or 'educate them to do things differently'

From discussions in comments, I failed to mention another consideration. The application that the service will be consumed within, has the ability for layer level security (at the application level). Therefore the group of users (that is fairly large) are assigned to a particular role, and that role will have access to the full 600 layers. Other roles will be limited.

  • Personally, I'd put together a question to the PM outlining the problem, advise on best practice, advise a way out, then leave it in their hands. At the end of the day, as soon as you have someone saying: 'but that's the way it was', you have your hands full. In this situation, I would do as above, then you've been professional, done yuor job, and the rest is up to them. I'd advise, also, to include anyone rich and famous in terms of where you work, on the email, to ensure the advice is out there, and that everyone knows what the advice was, and who gave it. – Hairy Dec 2 '11 at 10:37
  • You don't say the kind of webapp that will be used to browse the layers, but I assume that it is of kind of openlayers. In that case keep in mind that the browser could also present problems, as it will not issue more than a few (between 2 and 6) concurrent requests to the same server (including XHR, css and everything). See this article for the details and some alternatives (I usually go for the multiple cnames when IT is cooperative): stevesouders.com/blog/2008/03/20/… – unicoletti Dec 2 '11 at 10:50
  • @Hairy - I actually think that we can meet the requirements of the client with ArcGIS Server, and although its pushing the limits on whats possible with AGS, its still do-able, and we can still fall back on our prior advice to break the app into multiple apps. – Simon Dec 2 '11 at 11:17
  • 1
    I know it's doable, I have been working with clients who do the same, but I don't think it's advisable, which are different things. If they decide to have 10 clients who want all 600 layers, at one time, no matter what you're running AGS on, it will fall over – Hairy Dec 2 '11 at 11:21
  • 2
    See related question – Kirk Kuykendall Dec 2 '11 at 15:02

Used the Capacity Planning Tool to help compare one super heavy map service vs 4 lite map services, and the results indicate that the heavy map service is the way to go.

This may not be the right answer, and the capacity planning tool does not take into account every factor (e.g. user workflows) - let me know via comments what you think.

1 super heavy map service:
App Server CPU utilisation = 49.4%
Database Server CPU utilisation = 7.6%
Network load = 16 Mbps
Display Response Time = 0.88 secs

(Images can be seen in large by RC and open in new tab)

enter image description here

4 lite map services:
App Server CPU utilisation = 55.4%
Database Server CPU utilisation = 7.6%
Network load = 64 Mbps
Display Response Time = 0.32 secs each, so between 0.32 and 1.28 secs depending on web browser overheads

enter image description here

More logic to support the one map service approach:

  1. All layers are in the same map service, therefore;
    a. one request is sent to the server
    b. one SOC process draws the map
    c. one image is returned over the network

  2. The 40 layers are spread across 4 map services (10 layers each), therefore;
    a. 4 requests are sent to the server
    b. 4 SOC processes draw a map
    c. 4 images are returned over the network

1a and 1c will be faster and put less load on the network than 2a and 2c.

2b can use parallel processing to return a map quicker than 1b for a single user, but this will not be the case for many users. In fact, the overhead of the additional transactions being processed by the server in 2b (plus the additional network load of 2c) will see 1b scale much better as the number of users increases.

  • 2
    that sounds logical. Managing the 600-layer MXD doesn't sound like much fun. – Stephen Lead Dec 5 '11 at 22:19

Although using multiple services, scaling layers/labels, caching, and using non dynamic labels all help improve the web application experience, the initial hit to load all 600+ layers into one application will be noticeable by the end user. Especially the time it takes to populate the TOC. If you have to create a 600+ layer application I would definitely go with option #2. You may want to model your data struture against a data model (such as the local government data model).

The whitepaper below highlights some interesting best practice guidelines and performance statistics for ArcGIS Server web application configurations.


  • Good point on the TOC, but it actually loads fine. 'initial hit to load 600+ layers' = from a map request perspective, its still only making one request to one service. So its actually fairly quick for AGS to return the export UNTIL they start turning >20 layers on. – Simon Dec 4 '11 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.