Selecting the right technology: A case study

Selecting the right software technology can make a big difference in performance and scalability, and cost of the production system. The following case study shares an experience with a real customer implementation which clearly represents the value of selecting the right software technology.

Our customer had a requirement to design a Web application solution that would be used to collect national property location and census information during a three month national citizen declaration period. Citizens would report to regional government centers, use a local desktop computer to locate their home residence on a map display generated from a national imagery and geospatial features repository. Citizen would place a point

System Design Strategies 8 Software Performance C11144-12

on the map identifying their residence, and then fill out a reference table identifying their census information.

The citizen input would be consolidated at a centralized national data center and shared with all regional government centers throughout the declaration process.

The initial system design was developed using the ArcGIS Server 9.1 technology, using a centralized ArcGIS Server dynamic Web application technology to support browser clients located at 50 regional national sites.

Following contract award, the customer reviewed available technology options to finalize the system design.

Figure 8-27 shows three possible software technology options that were considered during the review.

Technology had progressed since the initial proposal, and there were three possible solutions that would support the customer operational requirements

Figure 8-27

Cache Performance Advantage (System Design Use Case)

The ArcGIS Server dynamic Web application was the solution provided in the initial design proposal two years earlier, and the ArcGIS Server 9.2 technology included improvements in Web application performance and user experience incorporating a Map Viewer application development framework for deploying images to an AJAX browser client.

ArcGIS Server 9.2 also included cache option where the reference map layers could be pre-processed and stored

System Design Strategies 8 Software Performance C11144-12

distributed client workstations. The point declaration layer point features can be exchanged with the centralized data center database using background network processing with current point displays maintained in a local client cache.

The ESRI Capacity Planning Tool was used to evaluate the architecture for the three different workflow technologies identified above. Peak system loads were estimated at 2000 concurrent users with standard Web productivity of 6 displays per minute. System design results are provided in the following paragraphs.

8.7.1.1 Dynamic Web Application

The ArcGIS Server ADF light Dynamic standard ESRI workflow was used to generate hardware requirements and traffic loads required to support the dynamic web application solution. Figure 8-28 provides the results of the capacity planning analysis.

Figure 8-28

ArcGIS Server ADF light Dynamic (System Design Analysis Summary)

Peak central data center traffic loads were estimated to reach 350 Mbps, well beyond the bandwidth available with the current data center Wide Area Network (WAN) service connection. Smaller regional office sites (10 concurrent users) WAN connections would need over 1.5 Mbps bandwidth. Larger regional office sites (50 concurrent users) would require WAN connections would need 9 Mbps bandwidth to support the peak citizen declaration traffic. Major infrastructure bandwidth increases would be needed to handle projected traffic flow requirements.

The selected central hardware solution was supported by Intel Xeon 5160 4 core (2 chip) 3000 MHz Windows

System Design Strategies 8 Software Performance C11144-12

64-bit Servers each with 16 GB memory. Total of 8 servers were required for the Web Application Server tier, 27 servers for the Container Machine tier, and three geodatabase servers (higher capacity data server could be used to support the geodatabase on a single machine).

8.7.1.2 Cached Web Application

The custom ArcGIS Server ADF light 1 layer Dynamic with Cached Reference layers workflow was used to support the cached web application workflow analysis. Software service time and network traffic performance targets were set for the custom workflow. Figure 8-29 shows the results of the system design analysis.

Figure 8-29

ArcGIS Server AJAXlight 1 layer Dynamic with Cached Reference Layers (System Design Analysis Summary)

Peak central data center traffic load estimates remained at 350 Mbps, the AJAX application traffic display would still be generated on the server leaving traffic requirements unchanged .

The selected central hardware solution was reduced to 5 servers required for the Web Application Server tier, 7 servers for the Container Machine tier, and minimum load on a single geodatabase server. This was a

significant cost reduction from the initial proposal.

A sample data set was used to evaluate map caching timelines, and the complete country reference map cache could be generated within one week of processing time. This would be well worth the effort, since there would be no need to update or change this data cache during the peak citizen declaration period (data would be static).

8.7.1.3 Cached Client Application

System Design Strategies 8 Software Performance C11144-12

performed very well on a standard Windows display environment and performed all the functions needed to support the citizen declaration requirements.

The ArcGIS Server Mobile ADF standard ESRI workflow was used to support the design analysis. Cached reference layers would be provided to each regional site in advance, and access would be provided over the a file share to the Mobile ADF client running on the local workstations. The ArcGIS Mobile client would exchange changes to the dynamic citizen declaration layer over the government LAN. User display

performance would be very fast, supported by the local reference map cache and the point layer in the Mobile ADF cache. The point layer cache was updated from the central data center geodatabase with each display refresh, and point layer edits were sent to the central server as a background data exchange. Figure 8-30 shows the results of our capacity planning analysis.

Figure 8-30

ArcGIS Server Mobile ADF 1 dynamic layer with Cached Reference Layers (System Design Analysis Summary)

Peak central data center traffic loads were reduced to 1.7 Mbps, well within the bandwidth available with the current data center Wide Area Network (WAN) service connection. Regional office sites would function well within the available 1.5 Mbps WAN connections, actual traffic less than 0.1 Mbps for the larger site loads. The existing infrastructure would be able to support peak WAN traffic loads with guaranteed service to each of the remote desktop locations (Mobile ADF client would continue to function as a standalone system if WAN communication were lost, and edits would be sent to the central server when communication was restored).

The central hardware requirements were reduced to2 composite Web/container machines servers and the data server load was minimal.

It was very clear that the cached client application provided significant cost and performance benefits over the centralized Web application dynamic solution included in the initial proposal. Pre-processing of map reference layers as an optimized map cache pyramid can significantly improve display performance. Use of an intelligent desktop client that can access reference layers from a local map cache can further reduce network traffic and

System Design Strategies 8 Software Performance C11144-12

improve display performance even more. Selecting the right technology can make a big difference in total system cost and user productivity.