In order to provide consistent performance, the GIS administrator must understand the user experience and how to modify the deployment when performance degrades. One way to achieve this is through monitoring ArcGIS server statistics, and ArcGIS server logs. Understanding the utilization pattern of deployed services is key and services with high demand but low performance may require tuning of known performance factors. Many performance issues are related to application design and cannot be resolved by simply adding more hardware or even tuning. Because of this, it is recommended to make performance testing and tuning a part of your development and release cycles.
To supplement the general enterprise GIS performance factors listed under Application Performance Considerations, the following is the relative performance of ArcGIS Services:
|Map Service Dynamic (MXD)||Medium||See below Map Service Performance Factors||REST Export Map|
|Map Service Dynamic (MSD)||Medium||Typically faster than Mxd; especially with complex document with only vector data||N/A|
|Map Service Cached||High||Format (IE: PNG for vector; JPEG for raster)||REST Export Map|
|Map Service Cached+Dynamic||Medium||Cache base map layers and use dynamic services for a few dynamic layers||N/A|
|Geocoding||High||Batching will improve performance||REST Find Address Candidates|
|Geodata||Low||Dependent upon volume of replication updates||N/A|
|Geoprocessing||Low||Dependent on complexity of the task. In general, RAM or Solid State Disks may improve performance||N/A|
|Image||High||Dependent on compression type, e.g. JPEG, PNG||REST Export Image|
|Mobile||High||Synchronization dependent upon number of edits||N/A|
|Network Analysis||Low||Dependent upon data format. SDC is the fastest. RAM or Solid State Disks may improve performance||REST Solve|
|WMS||Medium||Optimize map documents. Slightly slower than REST ExportMap||N/A|
|WCS||Variable||Dependent on output image type||N/A|
|3rd party services||Variable||Can impact overall performance and should be evaluated||N/A|
|WFS||Medium||Ability to construct efficient query filter||N/A|
*Where High implies a better performance relative to others
Map services are the most commonly utilized service of ArcGIS Server which is dependent on MXD/MSD files. Therefore, map service performance factors coincide with ArcMap documents as listed in the following table:
|Reduce number of features rendered||High||Typically controlled by setting scale dependency, number of layers|
|Reduce number of vertices||High||Controlled by number and complexity of fetched features|
|Reduce number of layers||Medium||Driven by user requirements and design|
Driven by user requirements
|Rasters||Medium||Separate raster content from mapservices; use image server services for rasters|
|Simplify complex symbology||High||Use annotation, simple marker symbol|
|Avoid projection on the fly||High||Use a common projection|
|Definition queries, spatial views||High||Driven by user requirements|
|Tune spatial index||Low||Consider single level vs. multi level index|
|Data source||Medium||Driven by user requirements. DBMS, FileGDB, Shapefile, SDC|
Non-Esri formats typically deliver lower performance. Esri ST_Geometry, Oracle SDO, SQL Server Binary, SQL Server Geometry, SQL Server geography.
*Where High implies a high impact, positive or negative, on overall performance
Image Service data sources have their own set of performance and scalability factors as seen in the table below. It should be noted some data sources, e.g. File Geodatabase, deliver higher performance, but at the same time are not very scalable (file I/O bound). In addition, the service overview configuration can have an impact on performance as will disk speed considerations.
Tuning and Optimization
When tuning services to achieve maximum throughput, the GIS administrator must consider the available resources. In general, a good starting point is 2.5 x #CPUs (for non-cache services), but when many services are deployed simply applying this generic recommendation could be problematic. It is best to categorize and estimate the demand for each service and to consider the available resources. Using this strategy, the administrator can gain understanding of the potential user patterns and partition the available resources to the published services. When the application is deployed, the administrator must monitor application behavior to confirm that actual user patterns match the predicted user patterns.
In order to provide consistent performance, the GIS administrator must understand the user experience and how to modify the deployment when performance degrades. One way to achieve this goal is to monitor the user experience, ArcGIS server statistics, and ArcGIS server logs. Performance may be reduced for many reasons such as: infrequent high demand for geoprocessing tasks, routing or optimization tasks, lack of geodatabase maintenance, and many other factors.
Many performance problems cannot be fixed by utilizing more hardware or tunning as they are related to the application design. Because of this, it is recommended to make performance testing and tuning a part of your development and release cycles.
One very common problem for dynamic map services is failing to optimize map content for performance.
Once the services have been deployed correctly and user load is increased, the administrator will need to decide if the deployment should be rebalanced to support higher user demand or to add more resources to the current deployment. ArcGIS server is highly configurable and can be scaled horizontally by adding new servers.
- Scaling out web server (web server farm)
- Scaling out ArcGIS Server SOM (multiple SOM)
- Scaling out ArcGIS Server SOC (SOC server farm)
- Data sources
- MxdPerfStat - Tool to help identify performance factors in MXD documents