ArcGIS Server System Architecture Memo

System Architecture Design Strategies for the e²M GIS Business Area’s
ESRI ArcGIS Server Development Environment

Purpose
The ArcGIS Server development environment will provide the e2M GIS team with the appropriate
development platform and the necessary experience to effectively and efficiently develop web mapping
application prototypes. In addition, this development environment will facilitate the building and
improvement of the skill sets required to pursue and win projects involving the design, development,
implementation, and maintenance of ArcGIS Server web sites for client use. The development
environment is designed based on recommendations from ESRI and represents the building blocks
required to deploy applications at client sites.

Business Case
In an effort to increase e2M’s marketability and service line offerings, the GIS Business Area has
developed system architecture strategies and virtualized the network infrastructure required to house
an ArcGIS Server development environment. ESRI’s ArcGIS Server is a leading geospatial technology that
allows organizations to distribute maps and GIS capabilities via Web mapping applications and services
to improve internal workflows, communicate vital issues, and engage stakeholders.

Many government and/or private sector entities are either converting to ArcGIS Server from previous
web mapping software (e.g. ArcIMS) or developing new web applications to display and analyze their
geospatial data and other web services (e.g. Google Maps, MS Virtual Earth). ArcGIS Server allows for
better internal coordination by providing users with the ability to view pertinent geospatial data in a
web based tool rather than accessing data through a more complex desktop application. The proposed
ArcGIS Server system design would support the ability to create optimized web mapping applications
that provide clients access to vital project-specific geospatial information.

System Architecture Design
The GIS team worked through a system design methodology aided by ESRI’s Capacity Planning Tool to
identify current issues and necessary changes to implement the proposed development environment.
The system design methodology recognizes that people, application technology, and selected data
sources are equally important in determining the optimum hardware solution. Figure 1 shows the basic
flow of the methodology and its primary components.

Knowlton, Richardson, Smiley June 17, 2009 Page 1

Figure 1: System architecture design process.

Process Components
The process components of system architecture design are people, applications, data resources, and
hardware. After determining the network limitations, the GIS team identified software and hardware
requirements for system architecture scenarios. Investment in hardware and network components
based on a balanced system design model provides the highest possible system performance at the
lowest overall cost.

• People: comprised of internal (e2M employees) and external (clients) users. Understanding user
needs, information products, and the procedures for making them establish a rationale for
establishing peak system workflow loads.
• Applications: software technology determines processing requirements (system loads) that must
be handled by the hardware solution.
• Data: the type of data source and what’s required to access it (data access requirements) shows
you how the processing load is distributed across the system architecture.


Balanced System Design
In Figure 2, the chain represents the factors that are linked in a system and therefore affect the system
performance. User workflows must be designed to optimize interactive client productivity. Work
request queues should be established to manage heavy batch processing loads and enhance user
productivity. The overall intent is to develop an efficient system that increases user productivity through
time and cost savings. The proposed development environment is designed with this intent in mind.

Figure 2: A balanced system load model leads to the highest system performance at the lowest overall cost.

Current Limitations
The primary limitation to the proposed infrastructure design is the network bandwidth, with the Fairfax
office being the biggest concern. The current bandwidth available for Fairfax is 1.5 Mbps and this is not
adequate for hosting GIS web services. The low bandwidth causes increased latency and display times,
essentially making web services very slow. The Denver office has 6 Mbps of available bandwidth which is
adequate for web service hosting. The bandwidth limitations require that the ArcGIS Server GIS web
services be hosted on Denver servers until bandwidth limitation are resolved in Fairfax.

ESRI ArcGIS Server System Architectures

Two-Tier Solution
The two-tier architecture (Figure 3) provides the best solution for an environment with a separate
database server. The two-tier solution includes GIS server and data server platforms. The Web server
and GIS server components are located on the GIS server platform, while the data server is on a
separate data server platform. This is a good configuration for sites with large volumes of data resources
or existing data servers.


Figure 3: Two-tier platform configuration

Three-Tier Solution
The three-tier configuration includes a single Web server with a separate map server/container machine
layer and a separate data server. The map server/container machine layer can be a single platform or
can be expanded to include several platforms, depending on the required site capacity. SOM load
balancing is provided by the GIS Web server service manager and multiple SOC instances can be
deployed to support optimum capacity requirements.

Figure 4: Three-tier platform configuration


Licensing Requirements
e2M’s current licensing stack is built using a host of development licenses. Specifically, an ESRI EDN
license consisting of development licenses for ArcGIS Server Advanced Enterprise Edition with 3D and
Image Server extensions, ArcSDE, and ArcGIS Info Workstation. In addition, e2M is also utilizing a
Microsoft Enterprise Agreement allowing use of development licenses for SQL Server 2008, Visual Studio
2008, and Microsoft Virtualization.

Conclusions
1. The e²M development environment is not designed and should not be implemented as a
production environment because of 1) hardware and bandwidth limitations, 2) licensing
restrictions, and 3) low availability and backup systems.
2. The e²M ArcGIS Server working group recommends entering a three-phase deployment strategy
consisting of 1) a pilot phase, 2) an initial production phase, and 3) a final implementation phase
in order to reduce implementation risk and allow for adequate skill development.
3. The goals and objectives of a web mapping site (i.e. process versus data) should dictate the
appropriate API when designing and developing an ArcGIS Server application, e.g. SOAP (.NET,
Java) versus REST (Flex, Javascript API’s).
4. A large-scale deployment of ArcGIS Server that is intended to support significant numbers of
users with numerous displays per minute requires large bandwidths typically only available
through data centers, i.e. colocation facilities.
5. The e²M ArcGIS Server working group recommends a three-tier stack consisting of Microsoft
SQL Server 2008 (database server), ArcGIS Server 9.3.1 (container machine/SOC), and a web
application server running IIS.
6. The e2M GIS team currently has the know-how and skill sets required to stand-up and support
LAN-based web applications capable of supporting company-wide project efforts.

Action Items
1. Install ArcGIS Server 9.3.1, ArcSDE, and MS SQL Server to establish our development
environment in Denver.
2. Procure a license and develop a proficiency in Adobe Flex so we can develop RESTful ArcGIS
Server applications.
3. Catalog and price a number of deployment scenarios in order to have an understanding of the
range of magnitude associated with specific ArcGIS Server configurations, e.g. two versus three-
tier deployments with and without redundancies and backups.
4. Demonstrate balanced system design by implementing best practices by following
recommended ESRI system performance tuning criteria.
5. Determine hardware specifications and bandwidths available at HDR’s Innovation Center.
6. Investigate current available hardware to support LAN-based web applications in a production
level environment.


Capacity Planning Tool (CPT) Analysis

SOAP vs REST

Requirements Analysis WEB TPH => WEB Users Network Unique 4 2

Types of Workflows
User Requirements 12,000 33 Bandwidth Display User Workflow Blink
Performance Summary Adjusted Platform and Network service times
Peak Workflow Network Mbps Traffic Think R_time Batch 0.01 Desktop Network Desktop Web Server Data
Workflow Data Source Users DPM/Client DPM Mbps DPH 12
3.5 Time sec DPM Latency Client Latency NWQ Xport WTQ WTS WAQ WA SSQ SS DBQ DBMS
Client
Local Clients 3 sec 1,000.0 Mbpd 100000 0.00001 0.010
1_ArcGIS Desktop Desktop SDE DC/DBMS 10
3.0 6.0 1000.0 10.01
NW Latency

2b_ArcGIS WTS/Citrix (w/image) WTS SDE DC/DBMS 10 6.0 1000.0 10.01 NWQ
3a_AGS9.3 AJAXlight Dynamic Server SDE DC/DBMS 6 2.5 10.0 1000.0 6.01 Network
WAN Clients 1.500 0.00002 0.000

Performance (sec)
WTSQ
1_ArcGIS Desktop Desktop SDE DC/DBMS 10 2.0 6.00 1000.0 10.01
WTS
3b_AGS9.3 AJAXMedium Dynamic Server SDE DC/DBMS 6 10.0 1000.0 6.01
3d_AGS9.3 AJAXlight Fully Cache Server SDE DC/DBMS 6 1.5 10.0 1000.0 6.01 Web Svr Q
Internet Clients Internet Clients = 4 Internet =0.8 Mbps 1.500 0.53 0.00003 0.000 0.000 Web Server
3b_AGS9.3 AJAXMedium Dynamic Server SDE DC/DBMS 4 6 24 0.800 1,440 1.0 6.7 3.29 18.2 6.01 0.089 1.333 1.680 0.187
App Svr Q
3c_AGS9.3 (Web Service) Server SDE DC/DBMS 6 10.0 1000.0 6.01
3e_AGS9.3 (REST API) Server SDE DC/DBMS 6 0.5 10.0 1000.0 6.01 App Svr

7a_ArcGIS Image Server Medium (preliminary) Server SDE DC/DBMS 6 10.0 1000.0 6.01 DBQ
8_AGS9.3 Globe Server (preliminary) Server SDE DC/DBMS 6 0.0 10.0 1000.0 6.01
Database
9_AGS9.3 Mobile ADF AGS Services Server SDE DC/DBMS 6 10.0 1000.0 6.01

3.0.11
Internet
1.0.1
1.0.2
1.0.3

2.0.4
2.0.5
2.0.6

3.0.7
3.0.8
3.0.9
3.0.10

3.0.12
3.0.13
LAN --

WAN --
2_Batch Reconcile and Post Process Server SDE DC/DBMS 6 10.0 1000.0 6.01
1.500 1.11E-05 0.000
Total Workload 4 0.800

1 Mbps Cores = 4 Minimal
Container Machines Intel Platform 8 GB RAM / Node SRint2006 WEBtier+SOC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
WEBtier+SOC Arc08 Xeon E5335 4 core (1 chip) 2000(8) MHz 36.0 SOC Container Machines
Average DPM/client .................................................. 6.0 DPM 0.864 Cores = 4 Chips = 1 4 9.0/Core
Total Required .......................................................... 24 DPM Service Times Capacity Multiple Platforms Fix
CPU Utilization ...................................................... 17% CPU 4 Users Seconds Display/Min Nodes Capacity Nodes
Peak Users .............................................................. 23.8 23.8 / Node 1.680 143 1 143 1.0
Recommend 64bit Operating System 2 Mbps 2 Mbps 8,571 TPH 8,571 TPH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Database Server Intel Platform 12 GB RAM / Node SRint2006
Arc08 Xeon E5335 4 core (1 chip) 2000(8) MHz 36.0 Database Server
CPU Utilization ........................................................ 2% CPU 4 Users Seconds Display/Min Nodes Capacity Nodes
Peak Users ............................................................ 214.3 214.3 / Node 0.187 1,286 1 1,286 1 1.0
Recommend 64bit Operating System 77,143 TPH 77,143 TPH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

SOAP w 4 core, 1chip, 2 Ghz
Bandwidth (Mbps): 1.5
CPU Utilization: 17%
Performance: 3.3 sec
Maximum Users: 4


Types of Workflows
Client
NW Latency
1_ArcGIS Desktop Desktop SDE DC/DBMS 10 6.0 1000.0 10.01
2.0
3a_AGS9.3 AJAXlight Dynamic Server SDE DC/DBMS 6 10.0 1000.0 6.01 Network
WAN Clients 1.500 0.00002 0.000
Performance (sec)

1.5 WTSQ
WTS
3d_AGS9.3 AJAXlight Fully Cache Server SDE DC/DBMS 6
1.0 10.0 1000.0 6.01 Web Svr Q
Internet Clients Internet Clients = 4 Internet =0.8 Mbps 1.500 0.53 0.00003 0.000 0.000 Web Server
App Svr Q
3c_AGS9.3 (Web Service) Server SDE DC/DBMS 6 0.5 10.0 1000.0 6.01
3e_AGS9.3 (REST API) Server SDE DC/DBMS 4 6 24 0.800 1,440 7.8 2.22 27.0 6.01 0.089 1.333 App Svr 0.709 0.093
Database
3.0.11
Internet
1.0.1
1.0.2
1.0.3

2.0.4
2.0.5
2.0.6

3.0.7
3.0.8
3.0.9
3.0.10

3.0.12
3.0.13
LAN --

WAN --

1.500 1.11E-05 0.000

Peak Users .............................................................. 56.4 56.4 / Node 0.709 338 1 338 1.0
Peak Users ............................................................ 428.6 428.6 / Node 0.093 2,571 1 2,571 1 1.0

REST w 4 core, 1chip, 2 Ghz
CPU Utilization: 7%
5/28/2009 Performance: 2.2 sec pg 1
Maximum Users: 4

Capacity Planning Tool (CPT) Analysis

SOAP vs REST


Types of Workflows
Client
Local Clients 3 sec 1,000.0 Mbpd 100000 0.00001 0.010 0.000
NW Latency
2.0
3a_AGS9.3 AJAXlight Dynamic Server SDE DC/DBMS 6 10.0 1000.0 6.01 Network
WAN Clients 1.500 0.00002 0.000 0.000

Performance (sec)
1.5 WTSQ
WTS
3d_AGS9.3 AJAXlight Fully Cache Server SDE DC/DBMS 6
1.0 10.0 1000.0 6.01 Web Svr Q
Internet Clients Internet Clients = 12 Internet =2.4 Mbps 5.000 0.48 0.00003 0.000 Web Server
0.000
3b_AGS9.3 AJAXMedium Dynamic Server SDE DC/DBMS 12 6 72 2.400 4,320 7.7 2.28 26.3 6.01 0.400 0.013 1.680 0.187
App Svr Q
3c_AGS9.3 (Web Service) Server SDE DC/DBMS 6 0.5 10.0 1000.0 6.01
3e_AGS9.3 (REST API) Server SDE DC/DBMS 6 10.0 1000.0 6.01 App Svr

Database

3.0.11
Internet
1.0.1
1.0.2
1.0.3

2.0.4
2.0.5
2.0.6

3.0.7
3.0.8
3.0.9
3.0.10

3.0.12
3.0.13
LAN --

WAN --
1.500 1.11E-05 0.000 0.000

Total Required .......................................................... 72 DPM Service Times Capacity Multiple Platforms Fix 50%
CPU Utilization ...................................................... 50% CPU 12 Users Seconds Display/Min Nodes Capacity Nodes +
Peak Users .............................................................. 23.8 23.8 / Node 1.680 143 1 143 1.0
Peak Users ............................................................ 214.3 214.3 / Node 0.187 1,286 1 1,286 1 1.0

SOAP w 4 core, 1chip, 2 Ghz
Performance: 2.3 sec
Maximum Users: 12


Types of Workflows
Client
1_ArcGIS Desktop Desktop SDE DC/DBMS 10
1.2 6.0 1000.0 10.01
NW Latency

3a_AGS9.3 AJAXlight Dynamic Server SDE DC/DBMS 6 1.0 10.0 1000.0 6.01 Network
WAN Clients 1.500 0.00002 0.000
Performance (sec)

WTSQ
1_ArcGIS Desktop Desktop SDE DC/DBMS 10 0.8 6.00 1000.0 10.01
WTS
3d_AGS9.3 AJAXlight Fully Cache Server SDE DC/DBMS 6 0.6 10.0 1000.0 6.01 Web Svr Q
Internet Clients Internet Clients = 12 Internet =2.4 Mbps 5.000 0.48 0.00003 0.000 Web Server
3b_AGS9.3 AJAXMedium Dynamic Server SDE DC/DBMS 6 0.4 10.0 1000.0 6.01
App Svr Q
3c_AGS9.3 (Web Service) Server SDE DC/DBMS 6 10.0 1000.0 6.01
3e_AGS9.3 (REST API) Server SDE DC/DBMS 12 6 72 2.400 4,320 0.2 8.8 1.20 49.9 6.01 0.400 App Svr 0.709 0.093
Database
3.0.11
Internet
1.0.1
1.0.2
1.0.3

2.0.4
2.0.5
2.0.6

3.0.7
3.0.8
3.0.9
3.0.10

3.0.12
3.0.13
LAN --

WAN --

1.500 1.11E-05 0.000

CPU Utilization ...................................................... 21% CPU 12 Users Seconds Display/Min Nodes Capacity Nodes
Peak Users .............................................................. 56.4 56.4 / Node 0.709 338 1 338 1.0
Peak Users ............................................................ 428.6 428.6 / Node 0.093 2,571 1 2,571 1 1.0

REST w 4 core, 1chip, 2 Ghz
5/28/2009 Performance: 1.2 sec pg 2
Maximum Users: 12

ArcGIS Server System Architecture Memo

ArcGIS Server System Architecture Memo

Recommended

Recommended

More Related Content

Similar to ArcGIS Server System Architecture Memo

Similar to ArcGIS Server System Architecture Memo (20)

ArcGIS Server System Architecture Memo