5

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

Improve this question
5
  • 7
    Hmm, fast map services. Then why ArcGIS ... ? – Nicklas Avén Sep 2 '11 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 '11 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 '11 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. – Peter Smith Sep 2 '11 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 '11 at 17:11
8

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:
http://www.esri.com/software/arcgis/arcgisserver/whitepapers.html

When dealing with hardware, I particularly recommend this whitepaper:
http://www.esri.com/library/whitepapers/pdfs/arcgis-server-virtualization.pdf

Improve this answer
5
  • @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 '11 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 '11 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. – blord-castillo Jun 23 '12 at 16:12
  • @blord-castillo, have you had a chance to update your thoughts for 10.1 (now 10.2.1?) – matt wilkie Jan 15 '14 at 22:12
  • Nope, but you just gave me a project for this week :) – blord-castillo Jan 16 '14 at 4:58
4

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.

Improve this answer
1
  • 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 '11 at 23:11
3

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.

Improve this answer
2

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.

Improve this answer
1
  • 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 '11 at 23:14
2

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.

Improve this answer

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.