I have an enterprise web application for a client that is hosted on a single GIS Server, a Web Adapter on a separate machine and an enterprise rdbms on a third machine. Currently, there is only one map service containing multiple layers. Some of the layers are used as visualization or reference layers while others are data points that are being edited/updated by the users. On average, there are about 400 - 500 requests to the service on a daily basis. I am seeing some performance issues with the application, most notably during times of high traffic use, and have been wondering if it is worth publishing some of the data layers that are being edited the most as separate services. Other suggestions are also welcome.
Map service performance issues can have a number of root causes:
- One or many of the layer data sources could have some issues slowing down data access. Things like complex database views, lack of indexes, network latency can all contribute to this
- Complex symbology can slow down rendering. Things like cross hatching, label halos, complex labelling rules can be to blame
- Showing too many features is a major cause of poor performance. Check to see that the service uses scale dependencies so that only a reasonable number of features are on screen at any given time. Eg, you don't need to see parcel layers at 1:100,000
Given that some of the map service layers are for editing and some are for visualisation I would move the editing layers to a separate service. That way editing activities won't impact visualisation activities as much. You could also make the visualisation layers a Map Image Service rather than a Feature Service to see if this improves things.
One other option to consider for your read only service. If there are too many features on screen at a given time, but you absolutely have to have them there, then you could consider tiling that service, which would make it super snappy.