APUC 2013: Best Practices for ArcGIS Server Web Services

Myself and John have spent a good three years in the Server support team at Esri Australia, and as a result we have a pretty good idea on the typical types of issues that can cause your services in ArcGIS Server to not perform as quick as you might want.

We are also both certified ArcGIS Server trainers, so we decided to deliver this session in more of a classroom style so that the audience could get the most of the session and hopefully take away some good tips on how they can get the most out of their ArcGIS Server services.

We kicked things off with the basics and stressed the importance of splitting up your operations layers from your basemap layers, and then cache those basemaps!

1

John gave some interactive examples on the effects the different cache settings would have on the final services, and looked at issues around transparency and the size of tiles.

Dynamic layers is an exciting newish (10.1+) capability on the dynamic map service, and I did some demos on how this can be utilised to just serve up one dynamic map service, but your applications can ask it to reorder layers, change symbolgy, even pull in layers that you did not originally serve up in the original service through a dynamic workspace.  Be easier if you go and have a play with the excellent Smart Application for Health and keep in mind that your only working with one map service that has one layer in it…

We then discussed some benefits of requesting for the actual geometries from a map service, and pulling them into your application.  The key benefit being more interactivity for your end-users.  I showed some different demos on the different settings on requesting geometries and when you should use them.

2

We wrapped up with what I think is the top tip of the entire session.  Monitor your services with the Beta System Monitor tool from Esri (Hint: Esri use this themselves to monitor their ArcGIS Server instances).

This tool not only keeps an eye on your ArcGIS Server service, but monitor the key infrastructure that is tied to it – you applications, the DBMS, the resources on the underlying servers, etc.  Not only can it provide nice looking charts and reports on how everything is behaving, it can even send you email alerts when certain warning conditions are triggered allowing you to fix things up before the users start ringing you up.

1

The bog box in this diagram is an isolated machine running the report server. The Report Server can pull in information from the relevant machines within your infrastructure and persist the information to MongoDB.

The bog box in this diagram is an isolated machine running the report server.
The Report Server can pull in information from the relevant machines within your infrastructure and persist the information to MongoDB.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s