I have been trying to figure out the best way to have fast map services. So far i have done lot of changes on the process side like scale rendering, analysis, projections, SDE data layer indexing, seperating map services etc. I have found some improvement.

I am at the point where I need to figure out the best hardware configuration that will provide fast map services. I have gone through some documentation from ESRI and it seems lot of information but hard to get develop clear understanding. Being a developer, I am looking for some solid/simple ideas on what i should be asking my Server team. This is the last option that i would like to explore.

Appreciate any feedback.

Thanks Jay

  • 7
    Hmm, fast map services. Then why ArcGIS ... ? Sep 2, 2011 at 7:41
  • Is your data dynamic or static? How many users do you expect? Which software will use you map service?
    – johanvdw
    Sep 2, 2011 at 11:32
  • 1
    Hardware is limited by budget - what is the approximate budget - but agree with Nicklas Avén you cannot speed up ArcGIS Server software.
    – Mapperz
    Sep 2, 2011 at 13:57
  • How many layers change on a daily basis and how big is that dataset? Could you download the data and render it clientside instead of using a map service for the changing data? If so, you could keep the entire dataset in server memory, completely skipping a disk hit. Sep 2, 2011 at 15:41
  • What alternatives or options would you suggest Nicklas? Maybe the use of AGS is out of Jay's control, and he is trying to make the best of what he has to work with.
    – user3461
    Sep 2, 2011 at 17:11

5 Answers 5


From a hardware perspective, the fastest option is a 4-core physical machine with minimum 8gb of memory hosting a SOM/SOC combination. When you add more capacity, add more physical machines and use load balancing between them.

That's pretty expensive though. From a virtualization perspective, you want to go with separate 1 core 4gb VM instances. Make one a SOM/SOC and the rest SOCs. If you have more resources, you can separate out the SOM layer, but separate out the web server layer first. Place a separate copy of the data on each machine; no network attached storage.

You can find more references at this page:

When dealing with hardware, I particularly recommend this whitepaper:

  • @blord - Yes; since the stock ESRI license is for 4 core that is a good point, then the addition of seperate machines to handle the load is good; that will add fail-over or just raw capacity in more SOCs.
    – D.E.Wright
    Sep 2, 2011 at 17:21
  • @Blord - But you can also utilize a couple big machines with the proper licensing and see high performance as well. The major key; strucutre you data/services well and make sure you configure the services properly. Scripts to break-up large tasks and merge back together are great thoughts as well.
    – D.E.Wright
    Oct 1, 2011 at 3:16
  • 1
    About time to update this for ArcGIS 10.1, which is structured very differently. I'll go through the docs and try to get a new answer typed up in late July. Jun 23, 2012 at 16:12
  • @blord-castillo, have you had a chance to update your thoughts for 10.1 (now 10.2.1?) Jan 15, 2014 at 22:12
  • Nope, but you just gave me a project for this week :) Jan 16, 2014 at 4:58

It looks like you are off to a good start. I have done many of those steps. As you can tell there isn't just one answer and different data sets can require different remedies. Some other things to try are below.

  • Use Compressed File Geodatabases for static data sets.
  • Cache, cache and more cache.
  • Generalize the data using dissolve and other tools.
  • Remove any unnecessary fields.
  • Store the data on local disks and not on the System disk of you can.
  • Use the fastest disk you can, especially RAID Arrays.

Also add in projection, if overlaying on top of the Esri Basemap make sure to reproject to Auxiliary Sphere.

  • Thanks Mike for the comment, I must add that I have a caching plan in place for all the data that can be cached. I am focussing on just the dynamic layers that change everyday. I am going to review thse two items: dissolve and fields removal. Thanks for the mention. Jay
    – jayGIS
    Sep 1, 2011 at 23:11

Not hardware-related, but if you're using featureLayers you should check out this blog post on maxAllowableOffset. This allows you to generalise your datasets on-the-fly, and can dramatically improve the performance.


Based on the ESRI version; look at the options of moving your most static data out of SDE to local fGDB to reduce DB traffic for data that is not changing much.

You really should look at caching as much as you can; so that you are not dynamically building a lot of data with each display.

The MSD/Optimized services are wonderful; but keep in mind things like Maplex labeling kills performance.

Many more things you can do; scaling/sizing hardware, good storage lots of things can be a help.

  • Thanks for the input, as I have mentiond in my comment above that I am only focussing on the dynamic services. I have all implemented almost all of these recommendations. I have found these very useful. Thanks Jay
    – jayGIS
    Sep 1, 2011 at 23:14

So far i have done lot of changes on the process side

In my experience, the users I see with slow performance, nearly always have a huge room for improvement at the service design end.
This video is the best I have seen on best practise for best practise around your map design at the MXD level.

Lets assume your services are as optimal as you can get them.

the best hardware configuration that will provide fast map services.

This is too hard to answer without having a better understanding of your setup, your users requirements, how many users you have, are they power-users or casual, how many services will they need, will there be peak times, are their network bottlenecks with bandwidth, etc etc etc.

I would start off by using the Capacity Planning Tool to start plotting in your existing infrastructure/requirements. This takes into account nearly every factor and will give you a traffic light diagram (Excel spreadsheet) on if your existing hardware will cope, or if you need to get additional SOC machines to spread the load or bump the hardware up on those machines.

Are you looking at doing this on a Virtual Environment? Virtual does have an overhead.
The capacity planning tool can factor this in, but please also consult this whitepaper.

I generally find looking at some of Esri's hardware partners useful, to gain an understanding on the sort of hardware that Esri recommends you putting ArcGIS Server on.

Take a look at Dell:

A Dell PowerEdge R610 Server Including:

  • One (1) Quad Core Intel® Xeon® X5687 3.60 GHz Processor, 12 MB Cache or Two (2) Quad Core Intel Xeon X5687 3.60 GHz Processors, 12 MB Cache
  • 12 GB RAM (3 x 4 GB Dual Ranked LV RDIMMs) for Four Core Server or 24 GB RAM (6 x 4 GB Dual Ranked LV RDIMMs) for Eight Core Server
  • 2 x 146 GB 15000 rpm Serial Attached SCSI (SAS) Disk Drives with RAID 1
  • PERC H700 Integrated RAID Controller 512 MB Cache
  • 2 x 502W Power Supplies for Four Core Server and 2 x 717W Power Supplies for Eight Core Server
  • Windows® Server 2008 R2, Standard x64 with 5 CALs

Other vendors available, and you do get discounts through buying ArcGIS Server with these bundles. I just use them to get an idea of the recommended hardware in more detail than the web-help.

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.