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.

 

Performance Factors

To supplement the general enterprise GIS performance factors listed under Application Performance Considerations, the following is the relative performance of ArcGIS Services:

Service Type Performance* Considerations Benchmark
Relative Performance of ArcGIS Server 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 Low 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 Low Batching will improve performance REST Find Address Candidates
Geodata High Dependent upon volume of replication updates N/A
Geometry Low   N/A
Geoprocessing High Dependent on complexity of the task. In general, RAM or Solid State Disks may improve performance N/A
Globe High   N/A
Image Low Dependent on compression type, e.g. JPEG, PNG REST Export Image
Mobile Low Synchronization dependent upon number of edits N/A
Network Analysis High 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 high service performance relative to others

Map Services

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 (Where High is the most performance degradation):

Category Impact* Considerations
Common Map Service Performance Factors
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
Cache raster layers Medium Driven by user requirements
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
Data type Medium 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 Services

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.

Category Performance Scalability
Image Service Data Source Factors
Image Server High High
ArcSDE Medium High
File Geodatabase High Low

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.

Scalability Strategy

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.

Tools

  • MxdPerfStat - Tool to help identify performance factors in MXD documents

Related Links

 

Filed under: