Network Communications 33rd Edition
Fall 2013 Network Communications 33rd Edition
Network communications provide the required connectivity for distributed GIS operations. Network capacity, in many cases, can limit the software technology solutions that perform well within your organization. System architecture design must identify and address network communication constraints and provide the right technical solution for a successful GIS implementation.
Communication technology advances are promoting a rapid shift in GIS client technology patterns, providing worldwide access to millions of data sources from a variety of desktop and mobile client devices in real-time.
These technology solutions work well if you have the required network connectivity. These solutions will not work if you do not have the required network connectivity. This chapter will show how to build a GIS that will perform well within the constraints of your network communications infrastructure.
- 1 Why is GIS traffic-intensive?
- 2 Types of networks
- 3 What is network capacity?
- 4 What is data?
- 5 GIS Client/Server Communication Protocols
- 6 Network Performance
- 7 Shared network performance
- 8 Performance modeling
- 9 Enterprise network architecture
- 10 Network Suitability Analysis
- 11 Network contribution to Web performance
- 12 Conclusion
- 13 CPT Video: Network suitability analysis
- 14 Previous Editions
Why is GIS traffic-intensive?
GIS applications rate among the heavy users of network traffic, along with document management and video conferencing. GIS technology provides an intuitive visual display to the user, enabling review of lots of maps for high user productivity. Each GIS map includes lots of data accessed from a variety of shared data sources enabling real-time display and analysis. Data must be transported to where the program is executed to display the information, generating lots of traffic across the network.
- What GIS does
- Displays data in a user-friendly graphic representation (maps).
- GIS map display represents overlay of many layers of data resources.
- User quickly sees what is important and requests another map display (up to 10 displays per minute).
- GIS data is typically shared from a central data repository.
- Data layers are accessed from the central data repository to complete each client map display.
- User productivity (viewing lots of maps) generates a lot of network traffic.
System architecture design should include an evaluation of bandwidth capacity (network suitability analysis) to ensure that peak traffic loads can be accommodated to satisfy user performance requirements.
Warning: Network bandwidth limitations (not enough bandwidth to handle peak traffic flow) can seriously constrict user performance during peak operational loads.
Types of networks
Network communication technology can be grouped into two general classes. These technology classes include LANs and WANs. the capacity of a particular network segment is identified by the maximum data transfer (measured in bits) that can be transported per second passing through that device. This capacity is called network bandwidth and is typically measured in millions of bits [megabits (Mb)] or billions of bits [gigabits (Gb)] per second.
Local area networks (LAN)
Figure 6.2 shows a drawing representing a local area network. Local area networks provide high-bandwidth communications for short distances. These networks connect local operating environments (usually within a building or local campus environment). Data transport over a single technology medium is single-threaded, which means only one data transmission can be supported on a single LAN segment at any time. The cost for LAN environments is inexpensive relative to other hardware costs supporting the system environment.
- Relatively short communication distances (within buildings or campus environments)
- Relatively high bandwidth capacity
- Relatively low-cost infrastructure, compared to alternative wide area networks
Best practice: Local area network design requirements can normally be addressed through recommended bandwidth specifications generated from the system architecture design network flow analysis.
Wide area networks (WAN)
Figure 6.3 shows a drawing representing a wide area network. Wide area networks provide an infrastructure enabling communication between remote locations. WAN connections normally provide much lower bandwidth than LAN environments, but transmission is possible over long distances. The cost for WAN connections is relatively high compared to LAN environments. The Internet is a global WAN environment.
- Relatively long communication distances between remote locations
- Relatively low bandwidth capacity
- Relatively high-cost infrastructure, compared to alternative local area network analysis
Best practice: Careful evaluation of remote site network bandwidth capacity is critical during a system architecture design analysis. Limited infrastructure capacity can be a primary factor in selecting the appropriate software technology solution.
Warning: Many GIS implementations have failed due to inadequate accommodation of peak WAN traffic flows. Remote client ability to use their GIS applications will depend heavily on having adequate network capacity to communicate with required GIS data resources.
What is network capacity?
GIS software solutions continue to generate more and more traffic across the network infrastructure with each release - and this is not the only technology making increasing demands on available network bandwidth. Bandwidth is often a limited resource. It is important that we conserve shared network resources, and select technology deployment patterns that make productive use of this limited resource. We can make a difference by the way we work and how we leverage available network resources in our technology selections.
Network capacity is identified as bandwidth.
The bandwidth you have will determine the amount of data you can transport.
- Data is a collection of digital computer information stored in media that have the capability to record and retain the data structure.
- Data can be transported from one location to another over different types of media.
- Each network protocol has limits to its supported rate of data transport, based on the technology used to support the transmission.
- Network traffic capacity is measured in terms of connection bandwidth.
- GIS uses a lot of data, and GIS users normally identify data in Megabyte units.
- Network bandwidth is based on Megabit units.
- 1 Megabyte (MB) = 8 Megabits (Mb).
Data capacity is measured in terms of megabytes or gigabytes when stored on computer disk. Megabyte is abbreviated using a large "B," while megabit is abbreviated using a small "b." One must remember 1 MB = 8 Mb when converting data volume from disk storage to network traffic. Network traffic also includes some protocol overhead, so a simple rule-of-thumb is to translate 1 MB of data to about 10 Mb of traffic.
Warning: Bandwidth capacity units are important. Make sure you have the right units.
LAN bandwidth capacity
Figure 6.4 shows the local area network protocols and available bandwidth capacity with current technology offerings.
- Ethernet connections are provided over twisted pair cable or optical fiber direct wired connections.
- Connection bandwidth capacity is limited by network switch or router device specifications.
- Cost of the network switch or router device is based on the provided connection capacity.
Best practice: Direct wired Ethernet networks provide the most stable network connections.
Local wireless connections:
- Local wireless connections are provided over a specified range of radio frequencies.
- Wireless bandwidth capacity depends on available technology.
Warning: Wireless connections are less stable than wired connections and often achieve much lower capacity than shown in their published specifications.
WAN bandwidth capacity
Figure 6.5 shows the wide area network protocols and available bandwidth capacity with current technology offerings.
Note: Wide area networks use a broad variety of protocols.
Telephone lines and Internet infrastructure:
- Dial-up modem
- Telephone service providers offer T-1, T-2, and T-3 communication gateways. Slightly higher capacity E1, E2, and E3 communication gateways are used by European service providers.
- Internet cable infrastructure connections include higher capacity OC3, OC12, OC48, OC193 lines that make up the service provider cloud infrastructure.
- Free space optical and microwave communications provide alternative transmissions when optical cable connections are not feasible.
- Satellite communications use microwave technology.
- laser transmitters send optical signals to line-of-site receivers over long distance hops.
- Cable TV infrastructure can be used for data transmissions, and is able to provide high bandwidth connections throughout the provided infrastructure.
Warning: The cost of wide area bandwidth capacity can be very expensive and capacity may not be available. Make sure to evaluate bandwidth requirements and availability during your system architecture design assessment.
Mobile cell phone network:
- Mobile cell phones communicate over radio frequencies bands, connecting to the nearest tower transmitters located in a cellular infrastructure throughout the service area.
- Cell phone wireless capacity depends on the available technology.
Warning: Make sure your smart phone device and service provider towers in your operating location satisfy your mobile bandwidth performance requirements.
What is data?
I remember a trip I made to the Chicago Science and Industry Museum when I was a young boy. They had a simple light bulb display that demonstrated how computers think. This was in the early 1960s, when computers were not common household appliances. The display showed how a series of on and off light bulbs could be used to add and subtract numbers - the scientific breakthrough that gave us computers. Who ever thought we could share our thoughts and ideas with a mechanical device that could be trained to do our brain work?
Figure 6.6 gives some clues on what data really is. Our thoughts, our ideas, our imagination. Data is a pattern that represents what we as humans do.
How has man communicated in the past?
- Maps and charts
- Language (a pattern of symbols that share our thoughts and ideas)
So what is data?
- Computers represent data in patterns of 1s and 0s.
- These patterns of 1s and 0s data are called.
- These patterns represent thoughts and ideas.
- These patterns that can be manipulated to produce information products that can be used in your work.
Data is not a physical thing that has mass and takes up space—the content is a pattern representing our ideas. Only the medium and method in which data is stored takes up space. Understanding this concept is important, since it explains why there are so many different ways to store and move data.
Our understanding of data is important since it suggests the physical laws of space and travel do not apply directly to data itself, only to the medium that is used to store and move data. This opens a world of possibilities to communicate and store data in ways that may not even be imagined today—humans are limited only by imagination.
There are satellites collecting high-resolution images of the world that can be displayed on a cell phone—an idea beyond imagination less than 10 years ago.
Data follows no laws of existence. It has no physical limitations.
Will science soon overcome the communication infrastructure limitations experienced today? It does seem likely.
Warning: Physical medium limitations for storing and moving data today can limit viable GIS technology choices.
What is client/server communication?
Figure 6.7 shows a simple diagram of how network communications work. Data is passed over the network using a variety of client/server communication protocols. Data is packaged for transmission across the network by the sender machine. Information is provided to aid in routing the data to its destination. Data is unpacked at its destination and returned to its original state.
- Communication processes located on client and server platforms define the transmission format and address information.
- Data is packaged for transport across the network.
- Packets contain communication control information required to transport the data from its source client process to the destination server process.
- Data package is translated to another medium for transmission across the network.
- Data package is returned to its original computer language for final processing.
- Data is unpackaged by the server and returned to its original state.
What are network transport protocols?
Figure 6.8 shows a simple overview of a network protocol stack. The communication packet is constructed at different layers during the transmission process. These include the application layer, transport layer, Internet layer, and network access layer. Each layer includes sublayers that complete the data packaging for transport.
A data stream from the host A application is sent through the protocol layers to establish a data frame for network transmission.
- The transmission control protocol (TCP) header packages the data at the transport layer.
- The Internet protocol (IP) header is added at the Internet layer.
- The media access control (MAC) address information is included at the physical network layer.
- The data frame is then transmitted across the network to host B, where the reverse process moves the data to the host application.
A single data transfer can include several communications back and forth between the host applications.
Best practice: GIS users generally measure data size in terms of megabytes or gigabytes. Data size on disk in megabytes (MB) can be converted to traffic in megabits (Mb) by multiplying by a factor of 10 (8 bits of data plus two bits of overhead for each byte of traffic).
GIS Client/Server Communication Protocols
Figure 6.9 provides an overview of the primary communication protocols used for GIS operations. Each protocol implementation includes client and server components to support data delivery. The client process prepares the data for transmission, and the server process delivers the data to the application environment. Roughly 1MB of data is needed from the server to complete a light-complexity GIS map display.
Network file services (NFS) and Common Internet File System (CIFS) Protocols
Support remote disk mounting enabling a client application to access data from a distributed server platform (network file share). All query intelligence resides in the client application, providing query instructions to access data located on the server platform. Data must be transferred to the client application to support query execution.
Benchmark testing with a remote shape file database identified 5MB per display data transfer (light-complexity display), showing a traffic overhead of four times the required 1 MB data transfer load.
- All query intelligence resides in the client application, providing query instructions to access data located on the server platform.
- Data must be transferred to the client application to support query execution.
- Chatty communications with shapefile data source resulting in high traffic overhead.
Best practice: Most large GIS files include a spatial index. The ArcGIS client will first download the spatial index, identify the location of the portion of the file required from disk, and then request delivery of the portion of the file required to complete the display (complete file deliver would not be required).
Database Access Protocols
ArcSDE includes client and server communication components. The database management system (DBMS) includes intelligence to support query processing.
SDE geodatabase traffic (light-complexity display) is roughly 0.5 Mbpd, with roughly 50 percent data compression when stored in an SDE geodatabase. Data is decompressed when processed by an ArcObjects client.
- ArcSDE includes client and server communication components.
- The database management system (DBMS) includes intelligence to support query processing.
- Compressed data is provided for network transfer and database storage (roughly 50 percent compression).
- Data is uncompressed by the client application (ArcObjects).
- Data must be transferred to the client application to support analysis and display.
ArcSDE API (Application server connect architecture)
- Initially SDE was developed to extend DBMS support for spatial data types.
- SDE would be installed on the server for translating ArcObject query calls for the supported DBMS.
- A proprietary ArcSDE API was used by ArcGIS clients to connect to SDE installed on the DBMS server.
An alternative ArcSDE client direct connect option is available that connects with a DBMS client application program interface (API) executed on the client desktop. The ArcSDE middleware functions are supported on the client platform, and the DBMS network client supports data transmission to the server. Query processing remains on the DBMS server.
Database (DB) API (ArcSDE direct connect architecture)
- ArcSDE client direct connect option connects with a DBMS client application program interface (API) executed on the client desktop.
- The SDE translation functions are supported on the client platform connecting the DBMS client, and the DBMS network client supports data transmission to the server.
- Query processing remains on the DBMS server.
Best practice: Direct connect is the recommended database architecture solution.
ICA and RDP Protocols
The Microsoft Remote Desktop Protocol (RDP) and Citrix Independent Computing Architecture (ICA) protocols support remote terminal display and control of applications hosted on a shared Windows Terminal Server (Remote Desktop Services).
- The ArcGIS application running in the data center accesses the GIS data and generates the map display.
- The display output is delivered to the user terminal client display.
- The amount of data in the map display output is roughly 100 KB, a factor of 10 less than the original source data used to generate the display.
Microsoft (RDP) and Citrix ICA protocols:
- These protocols support remote terminal display and control of applications hosted on a shared Windows Terminal Server.
- Both protocols transmit display and control information to the terminal client.
- Both the Independent Computing Architecture (ICA) protocol and Remote Desktop Protocol (RDP) compress data for transmission.
- Maps from vector-only data layers can generate less than 28KB of traffic per display. Compression of common pixel color areas is very good, resulting in the lower traffic volume.
- Maps that include an imagery layer generate up to 100KB of traffic per display. Imagery results in color variation between most pixels, limiting the amount of traffic compression.
Best practice: Most GIS customers choose to use the Citrix ICA protocol for hosting centralized ArcGIS for Desktop operations. Citrix ICA protocol provides the best user experience and advanced terminal services administration.
The Hypertext Transfer Protocol (HTTP) is a standard Web transmission protocol. In this transaction-based environment, service selection and display are controlled by the browser client. Data is compressed for transmission. There are a variety of Internet Protocols that can be implemented within the HTTP framework.
Web service map images can be embedded in a web browser.
- Size of the map image is determined by server administrator during web publishing.
- 50–200KB map image files are common with each display transaction (500Kb to 2Mb of traffic per display transaction).
Web service map images support rich Internet application clients (ArcGIS for Desktop, Silverlight, Flex, iOS).
- Size of the map image is determined by the resolution of client display.
- 200–400KB map image files are common with each display transaction (2Mb to 4Mb of traffic per display transaction)
Warning: Traffic for ArcGIS for Desktop clients is often higher because of the larger image transfers. Image size is directly proportional to the physical screen display resolution and map display size; thus, larger image displays result in higher traffic.
Network performance can be divided into three simple parts that explain network performance impacts. These parts include network transport time (similar to software service time on hardware platforms), network travel time (this is the round-trip packet travel time we call latency) times the number of round-trips (we call chatter), and queue time (wait time for a transmission to get on the network due to network congestion).
What is network transport time?
Figure 6.10 shows a simple overview of a WAN connection. Network transport time is the time required for the network gateway (switch, router, modem) to process the traffic on the network. The network connection design constraint is established by the weakest (lowest bandwidth) shared network component within the transmission route.
- Network transport time = minimum network gateway processing time (display traffic/bandwidth)
Rule of Thumb: Transport time per display = Mbpd / minimum gateway bandwidth (Mbps)
- SDE geodatabase traffic = 5 Mbpd
- Minimum bandwidth connection = 10 Mbps
- Network transport time = 0.5 sec (5 Mbpd/10 Mbps)
Network transport time examples
Simple match can explain many of the performance impacts we see from limited bandwidth connections. Many people do not bother to do the math, so here we try to identify the value of doing the homework. Most network design problems are quite simple to avoid if you do your homework.
The data transfer traffic and the network bandwidth can be used to estimate minimum network transport times for a single map display transaction.
Rule of Thumb: A typical light GIS application requires up to 1 MB of data to generate a new map display (2 MB for a medium display). Typical terminal/browser display traffic is about 100 KB of data for the same light map display.
Figure 6.11 shows typical data transfer requirements in megabytes, shows the conversion to megabits of traffic for transmission, includes any adjustments of this data performed by the communication protocol, and identifies the total volume of traffic in megabits that must be transmitted (protocol overhead may be greater than what was used in this sample conversion).
The minimum data transport times are calculated for five standard bandwidth solutions.
- 56 kilobits per second (Kbps) for standard dial-up communications
- 1.54 megabits per second (Mbps) for typical WAN communications
- 10 Mbps, 100 Mbps, and 1 gigabit per second (Gbps) for LAN communications
Warning: Any existing data traffic on shared network segments would increase these network transfer times.
File server configurations support query from the client applications.
- When selecting data from a shapefile, the total file (file index for large spatial data file formats) must be delivered to the client for query processing.
- Data not required by the application is rejected at the client location.
- This accounts for the considerable amount of traffic overhead experienced by these communications.
ArcSDE client/server configurations support DBMS query processing on the server platform.
- The query processing includes locating the requested data and filtering that data so only the specific data extent requested by the client is returned over the network.
- If the client application requests a small volume of data (e.g., point data or a single parcel in a parcel layer), the resulting data transfer can be small and network transport time would improve accordingly.
Best practice: Desktop applications accessing file or DBMS data sources perform best in a local area network environment. Transaction-based services, or persistent Windows Terminal Server connections, provide reliable environments for processing over less stable wide area network connections.
Warning: Several problems can occur when connecting a client application to a DBMS across a WAN connection.
DBMS connection across a WAN
A DBMS connection across a WAN connection can result in the following:
- Increased traffic between the client application and the DBMS is only one consideration.
- Network latency for chatty communications contributes to significant performance degradation and is addressed in the following section.
- A third issue is the need for a persistent connection between the client application and the DBMS.
- If the client network connection is lost during a DBMS transaction the data may not be received by the DBMS.
- When the network connection is restored, the DBMS and client application session may not be in sync.
- Once the application session is out of sync, the DBMS will protect data integrity and roll back to the last database commit.
- This can result in lost work when accessing a DBMS over an unstable network connection – an event that can contribute to user frustration and reduced productivity.
Best practice: When you must communicate with a DBMS over a WAN, consider distributing the data using either our geodatabase replication services or disconnected editing using feature services.
What is network latency?
Figure 6.12 shows how latency impacts display performance. Network latency can sneak up on you. It does not exist in the local network (if you have good switches and routers), and may not show up in your testing. It is not easy to identify how chatty your software application is. This can be a big problem for remote users — Satellite connections, for example, can have latency exceeding 1 second for each round trip. Wireless latency values can also be high.
Network latency is the round-trip travel time for a single communication packet. Many applications require several sequential round trips to the server and back to complete the display transaction. Each round trip is a chat, and most applications require several sequential round trips to the server to complete a display transaction. The more chatty the application, the more latency will impact display performance.
- Total latency delay = latency x chatter
- Latency = measured round-trip travel time (milliseconds)
- Workflow chatter = number of sequential round trips for an average display
Rule of Thumb used for design purposes:
- Medium-complexity SDE/file chatter = 200
- Web/terminal client chatter = 10
Network latency example
Figure 6.13 shows a simple example demonstrating latency performance impacts. Several similar use-cases have played out in system design consulting and performance tuning. A simple ping command can identify a potential latency performance issue for chatty applications.
Normal database access protocols are "chatty," which means a typical database query requires a large number of trips to and from the server to complete the client display transaction. There are several trips to and from the server (query transactions) for each layer in the map display. Following examples assume that 200 query transactions are required to support a single map display.
Network latency can impact bandwidth utilization over long WAN distances. Latency is easy to measure, using a simple Windows command prompt (tracert "server host name"). Results provide the number of network hops and the associated network latency time for a single trip.
The network latency example compares latency impact for local clients (1 msec latency) with remote clients (30 msec latency).
For LAN environments, network latency is very low (typically < 1 millisecond per trip to the server).
- Many trips between the server and client have limited performance impact.
- The primary system latency contribution is client and server processing service times.
For longer WAN distances that involve several router hops, there can be a measurable network latency delay. For chatty database connections, network latency can have a measurable performance impact.
- Total transaction time over the WAN (including cumulative network latency) is 7.47 seconds.
- The maximum bandwidth utilized by a single user on this WAN connection is 1.34 Mbps.
Best practice: Latency should be reviewed for performance impacts when remote clients are accessing chatty applications over long distances or unstable communication connections.
Currently, many global WAN connections include satellite communication links. The fastest communication transfer is limited by the speed of light, which for very long distances will introduce a minimum bandwidth latency that technology will not overcome. Good performance over WAN environments results from protocols that minimize trips (communication chatter) between the client and server platforms.
Warning: Latency for en-route satellite communication hops can be over 1 second, generating unacceptable delays for chatty applications.
CPT network latency performance delays
Network chatter is included in each workflow on the CPT Workflow tab. Network latency is defined on the remote site network segments for each user workflow. The CPT will calculate network latency delays by multiplying network latency by workflow chatter and include the result in calculating display response time.
Latency is addressed for each remote location in the CPT Calculator tab.
Latency is addressed for each remote site network in the CPT Design tab.
Network contention is all about busy networks. Network contention delays are similar to what we experience in rush-hour traffic on a freeway. It is really important to establish sufficient network capacity for peak traffic loads — this is often the time that you need to get work done, and if you do not have sufficient bandwidth the system will fail to support your critical productivity needs.
Figure 6.14 shows multiple user communication packet transmissions on shared network segments. The top diagram shows random network traffic transmissions with no packet collisions, and the bottom diagram shows increased random traffic transmissions with a packet collision. The total number of clients that can share a single network segment will vary with network traffic transport time (size of data transfer and network bandwidth). Only one client data frame can be transmitted over a shared network segment at any time, and display response time will slow down when user communications are transmitted at the same time due to packet collisions (network contention).
With older switch technology, multiple transmissions at the same time on a shared Ethernet network segment would result in collisions. When a collision occurs, each client would delay and then retransmit to complete data frame delivery. Ethernet segments would fail rapidly during saturation because of the high number of transmissions.
Best practice: Maintain peak traffic for shared segments to levels below 25–35 percent utilization with older Ethernet hub technology.
Ethernet switches today include options for configuring shared segments in a full duplex mode, which, configured properly, take advantage of switch buffer cache and improve transmission efficiency.
Best practice: Plan peak traffic for shared segments to levels below 60 percent utilization with full duplex Ethernet switches.
Models use average loads. Live loads have peaks and valleys, which are quite predictable using queuing theory (because you are dealing with very large random populations). If the network gets too busy, user productivity will slow down. If you are way off in your network design, work can slow to a crawl. Network suitability analysis should be done for every design to avoid performance failures.
Shared networks must adjust traffic flow to accommodate random transmission arrival times. When peak traffic loads remain within the available bandwidth, users will not experience network delays. On the other hand, when concurrent transaction arrival times exceed available network capacity, users will experience delays. Concurrent transactions must wait for network connection, resulting in transmission delays.
- Delays increase during heavy traffic loads as the network reaches saturation.
- Wait time (queue time) is a function of network transport time and bandwidth utilization.
- Higher traffic per display and busier shared network segments contribute to longer transmission delays.
Network design planning factors
Figure 6.16 puts together the pieces we have talked about throughout this chapter and summarizes where the numbers used in the CPT network analysis come from.
Best practice: Baseline map display traffic design factors are validated during Esri performance benchmark testing.
Baseline traffic for a light-complexity dynamic map display.
- GIS application access to a shapefile data source generates up to 50 Mb traffic per map display.
- GIS application access to a geodatabase data source generates up to 5 Mb traffic per map display.
- GIS terminal client access to Windows Terminal Server application generates up to 0.28 Mb traffic per map display (vector-only data source).
- GIS terminal client access to Windows Terminal Server application generates up to 1 Mb traffic per map display (imagery layer in data source).
- GIS web browser client access to a web mapping service generates 1–2 Mb traffic per map display.
- GIS rich client access to a web mapping service generates 2–4 Mb traffic per map display.
Generation of the baseline map display traffic design factors is shown in Figure 6.17.
Summary of the generation of baseline network traffic flows:
- Data per display (KBpd) was presented in the discussion about GIS client/server protocols.
- Adjusted data per display (KBpd) was presented in the discussion about network transport time.
- Traffic per display (Kbps) is 10 times the adjusted data per display.
- Baseline traffic flow shown on the CPT Workflow tab is displayed in Mbpd (Kbpd/1000).
Best practice: Capacity Planning Calculator workflow traffic targets are further modified based on performance adjustment parameters gathered from Esri performance sensitivity benchmarks.
Network traffic adjustments
Network planning factors provide a starting point for completing our network suitability analysis. A baseline estimate of the network traffic per display for each user workflow is established from software technology pattern templates and internal benchmark testing. The actual traffic per display for a specific user case will also depend on the client communication protocol (server output format) and the workflow data source.
A series of benchmark tests were performed to evaluate traffic impacts between available ArcGIS for Server map output formats. Results of these benchmarks were used to establish baseline adjustment factors for use in generating custom data flow estimates for variable server output formats. Figure 6.18 shows the traffic adjustment factors applied to the baseline client display traffic based on selected output format.
ArcGIS workflow server output formats:
- JPEG is recommended for imagery output.
- PNG8 is a light-weight Portable Network Graphics lossless data compression supporting up to 256 colors and transparency. Can be used for business layers where high color contrast is not required.
- PNG24 is a medium-weight Portable Network Graphics lossless data compression supporting up to 16 million colors and transparency overlay. Provides more color depth and transparency control than PNG8.
- PNG32 is the highest quality Portable Network Graphics lossless data compression. Provides the best support for graphics with gradients, varying colors, rounded edges, and transparency.
- PDF is Adobe's Portable Document Format. Delivers high-quality plot files from your map document.
- Feature service delivers GIS feature data to the client for editing purposes.
- ICA is the Independent Computing Architecture protocol developed by Citrix for communications between Windows Terminal Servers and Citrix remote client terminal displays.
Note:Output performance adjustment factors are included in a look-up table maintained on the CPT Calculator tab.
Data source format)
A series of benchmark tests were performed to evaluate traffic impacts when using different data source formats. Results of these benchmarks were used to establish baseline adjustment factors for use in generating custom data flow estimates for variable workflow data source formats.
Figure 6.19 shows the traffic adjustment factors applied to the baseline client display traffic based on selected GIS mapping vector data source formats.
Values show relative performance compared with an ArcSDE geodatabase data source.
- SDE DBMS: Baseline SDE geodatabase data source
- Small file geodatabase: Small file geodatabase data source
Best practice: A small file geodatabase works well for hosted web services. It is recommended that a copy of the data be deployed on the local disk for each ArcGIS for Server machine.
- Large file geodatabase: Large file geodatabase data source
- Small shapefile: Small shapefile data source (data source fits in application server memory)
- Medium shapefile: Medium shapefile data source (medium-size county dataset)
- Large shapefile: Performance with a large shapefile data source can be marginal
Best practice:Move data from a shapefile to a file geodatabase for best performance.
Figure 6.20 shows the traffic adjustment factors applied to the baseline client display traffic based on selected GIS imagery data source formats
Values show relative performance compared with Imagery served from an ArcSDE geodatabase data source.
- SDE DBMS: Imagery stored in an SDE geodatabase.
- TIFF_uncompressed: Uncompressed Tag Image File Format; uncompressed files can be quite large.
- TIFFLZW_compress: LZW is a lossless compression. Works best with raster data that has solid color ranges available for compression. Less effective with imagery where there is color variation between pixels.
- TIFFJPG_compress: Lossy JPEG compression of a TIFF file.
- JPG2000: Upgraded JPEG (Joint Photographic Experts Group) compression algorithms published in 2000. Supports lossless and lossy compressions. Published as an ISO standard. Provides several enhancements over standard JPEG compression. Requires encoders/decoders that are complex and computationally demanding.
- MRSID: LizardTech Multi-Resolution Seamless Image Database format that uses a mix of techniques supporting lossless and lossy compressed datasets for use by the GIS community.
- ECW: Enhanced Compression Wavelet format optimized for aerial and satellite imagery. Developed by Earth Resource Mapping, and is now owned by ERDAS, which is owned by Intergraph.
- IMG_ERDAS: ERDAS Imagine image file format.
A variety of imagery sources and formats are available, and methods for collecting and sharing imagery data sources is of high interest within the GIS community. Technology is rapidly evolving to capture and deliver opportunities for leveraging and sharing imagery data products.
Note:Data source format performance adjustment factors are included in a look-up table maintained on the CPT Calculator tab.
A single workflow network performance analysis can be completed using the CPT Calculator.
Best practice: CPT Calculator is a useful tool for evaluating single workflow network traffic contributions and the impact of available network capacity on remote site user productivity.
Warning:The CPT Calculator is limited to addressing a single workflow environment. Additional network traffic from other business operations will need to be included to complete the analysis.
Enterprise network architecture
Figure 6.21 shows a typical IT drawing, and the colors used match the network locations used in the CPT. The CPT Design tab is an information product matching the IT diagram, once you understand the network and user workflow relationships.
GIS user workflows access applications, services, and/or data sources maintained within the enterprise data center. Users may be located on the LAN, at remote locations over the WAN, or operate from mobile clients over wireless WAN or Internet connections. Remote and local users may also access a variety of web services over the public Internet.
The enterprise GIS network communication diagram shows GIS users located at three remote sites: one connected over an Internet connection and the other two connected over a WAN connection. Additional GIS users are located within the central LAN environment.
- Remote user site connections are shown in green.
- Central data center connections are shown in gray.
- Data resources and web services are published from the central data center.
- Remote site users access central data center resources across the Internet and WAN connections.
Network connections within the local LAN infrastructure can normally be adjusted to accommodate peak traffic loads without significant cost impacts. Remote WAN and Internet connections often present constraints that must be addressed in the system design, and may limit the viable software technology deployment options.
Warning: Network bandwidth limitations (not enough bandwidth to handle peak traffic flow) can seriously constrict user performance during peak operational loads.
CPT Design user requirements module configuration establishes a foundation for completing the network suitability analysis.
Best practice: GIS user requirements analysis should be completed before establishing the final system architecture design.
The CPT Design requirements analysis module layout makes it possible to represent workflow display traffic flow across the appropriate service provider network connections.
Best practice: System design configuration begins with results from a user workflow analysis.
Results of a user workflow analysis review establishes performance parameters for the system architecture design. Figure 6.22 shows a sample of the results of a workflow analysis review (Business Requirements Summary):
- User requirements include three workflows (DeskEdit, DeskView, and WebMap)
- Users are located at different network locations (local users, remote site 1, remote site 2, and public internet)
- Peak workflow usage is identified for each network location
- Local Area Network (peak users for each workflow)
- Remote site 1 (peak users for each workflow)
- Remote site 2 (peak users for each workflow)
- Public Internet connection (peak transactions per hour for WebMap services)
CPT Design requirements section is configured to represent the user locations and network connectivity. Once the requirements section is properly configured, the CPT (Excel) completes the network suitability analysis.
Best practice: Configuring the requirements analysis module establishes a foundation for completing the CPT Design tab network suitability analysis.
Network Suitability Analysis
Many network administrators establish and maintain metrics on network utilization, which help them estimate increased network demands when planning for future user deployments. The CPT Design tab includes a network suitability analysis which uses display traffic from the Workflow tab to compute peak site traffic workflow loads. Sum of all site traffic workflows is compared with the site bandwidth to identify peak network utilization. Network bandwidth should be configured at about twice the peak traffic loads to avoid contention and performance impacts.
Computing network utilization
Figure 6.23 shows the user workflow and peak site traffic. The CPT Design tab includes a network suitability analysis which uses display traffic from the Workflow tab to compute peak site traffic workflow loads.
- Identify user workflows. These are the workflows that will generate the network traffic.
- Identify average display traffic (Mbpd). This is the traffic generated across the network for each user display transaction.
- Identify user locations. Identify the network route between the user location and the data center.
- Compute workflow traffic. Workflow traffic is the product of user productivity and display traffic.
- Traffic = productivity (DPM) x Mbpd / 60 seconds
- Compute site traffic. Total traffic that will be communicated over the shared network connections.
- Site Traffic = Sum (workflow traffic for that site)
Productivity is a measure of user display activity represented in average displays per minute. Each new user display requires a workflow transaction that generates network traffic. The total amount of traffic divided by available bandwidth is the network utilization. The sum of all the site traffic workflows is compared with the site bandwidth to identify peak network utilization.
Calculating network utilization.
- Identify site bandwidth.
- Identify peak site traffic.
- Compute network utilization.
- Utilization = traffic / bandwidth
Note: The network suitability analysis evaluates how much of the available bandwidth (utilization) will be required to meet peak system loads (if you have too much traffic for the available bandwidth).
For many GIS workflows, the user computer display response time can be a factor in reducing user productivity. Slow display response times reduce user productivity.
Figure 6.24 shows the factors that make up user display response time. The total service time includes the computer processing and network transport times for each display. The queue time includes any system wait times due to processing contention. The total response time also includes network latency delays. Queue time increases as the network and platform system components get busy, and the queue time profile is predictable for large populations of random transmission requests (computer processing workflow transactions). [Queue time calculations] will be discussed in more detail in chapter 10.
Display response times can be computed for each workflow, based on the total of all system component service times and queue times during peak system loads.
- Calculate network queue times.
- Calculate network transport times.
- Network response time = transport + queue times + latency.
- Calculate workflow display response times (platform response times + network response times).
It is important in a design analysis to validate user productivity. If established use productivity can not be maintained due to system contention, the estimated system loads would be more than what is possible in a real environment.
Validating user productivity.
- Cycle time = 60 seconds / user productivity
- Computed think time = Cycle time - workflow response time
- Minimum think time is the minimum time required for user decision and input (defined by workflow).
The workflow is valid if computed think time > minimum think time. User productivity must be adjusted if the workflow response time does not support minimum think time.
Warning: The workflow is not valid if minimum think time exceeds computed think time.
Figure 6.24 shows the CPT Design Workflow Performance Summary. The Workflow Performance Summary shows workflow response time as a stack of software service times, network transport times, associated queue times, and network latency (available once system level performance validation and any required workflow productivity adjustments are complete).
Workflow performance is the sum of the following component parameters:
- Software service times
- Network transport time
- Associated component queue times
- Network latency delays
User productivity adjustment
Normally, once you identify that you do not have enough bandwidth, you talk with the network administrator about network upgrades. If you are not able to upgrade the network, you can look for another distributed GIS solution pattern that will avoid the network bottlenecks. The RESET ADJUST function is useful in identifying how wrong a solution might be - what are the user productivity impacts? This is often helpful in validating a more costly end solution.
Figure 6.25 shows what happens during heavy traffic conditions, when network bandwidth is saturated beyond capacity limits.
- User productivity determines the average server transaction request rate.
- 10 displays per minute, or one display every six seconds.
- Users will start to slow down when they are not able to maintain their productivity rate.
- To maintain productivity, the user must receive the requested map display from the server (response time) and have sufficient time (minimum think time) to review the display information and submit the next transaction request.
Warning: If the display response time plus the minimum think time exceeds six seconds, the user will not be able to maintain a productivity of 10 displays a minute and will have to slow down.
- The CPT Design tab calculates display response time and available user think time for each user workflow.
- If the computed think time is less than the workflow minimum think time, the workflow productivity must be reduced to show a valid workflow load.
The CPT Design tab has an ADJUST function, cell AF2, that automatically adjusts user productivity to honor identified minimum think time requirements.
Best practice: The RESET ADJUST function can be used to identify maximum user productivity available with increasing bandwidth.
Warning: The RESET ADJUST function does not perform well with very small network transport times. Network bandwidth should be increased to handle traffic flow.
Figure 6.25 shows a valid workflow following the use productivity adjustment. Once minimum think time equals computed think time, the CPT identifies a valid workflow.
- Reduced workflow productivity increases workflow cycle time.
- Reduced workflow productivity reduces network utilization.
- Reduced network utilization reduces network contention (queue time).
- Reduced queue time with increased cycle time increases computed user think time.
Note: There will be further discussion about system performance factors and relationships that impact system capacity and user productivity in Lesson 10.
Best practice: Network suitability analysis is an important part of system architecture design; making sure you have sufficient network infrastructure to ensure remote user productivity is critical for implementation success.
CPT Design network suitability analysis
Network Suitability Analysis is completed by the CPT Design tab as you configure user locations, input peak workflow loads, and identify network bandwidth.
Best practice: Increase network bandwidth to roughly twice expected peak traffic flows.
The RESET ADJUST function on the CPT Design tab can be used to demonstrate impacts on user productivity due to network bandwidth constraints. The RESET ADJUST function reduces user productivity for all workflows adjusting system loads to fit within existing infrastructure capacity constraints.
Workflow performance summary
Figure 6.26 shows the Workflow Performance Summary following the productivity adjustment. Once you have resolved all workflows to a valid workflow solution, you can review the workflow performance summary to evaluate workflow response times for each user site location.
The Workflow Performance Summary will identify queue times for the reduced productivity workflows.
Once you complete your network suitability analysis, you should work with the network administrator to identify appropriate network bandwidth upgrades.
Best practice: Network bandwidth should be roughly twice the expected peak traffic loads to avoid performance bottlenecks.
Warning: Network traffic utilization over 60 percent could contribute to network contention.
Once you agree on bandwidth upgrades, you can enter them in the CPT Design to complete your analysis.
Network performance parameters are identified on the CPT Workflow tab. Workflow display chatter, client display traffic, and database traffic columns are established when creating a user workflow and are available in a look-up table located on the CPT Workflow tab.
Network contribution to Web performance
Figure 6.27 shows the network contribution to Web display performance. Network performance counts. Network transport time is a major contribution to web client display response times.
- Web services tend to deliver higher display traffic than WTS ArcGIS for Desktop clients.
- Server display render time can be much less a factor than the network connection.
- Network performance improves with increased bandwidth.
- 45 Mbps bandwidth connection is 30 times faster than a 1.5 Mbps connection.
- Light display traffic performs much better than heavy display traffic.
Best practice: Network performance impacts should be considered carefully during design and deployment of web services.
Network bandwidth suitability is an important part of the system design process. Expanding GIS technology patterns, particularly over wide area and mobile cellular networks, have place heavy demands on the network infrastructure. Available network capacity, particularly the last mile in connecting to the client, can determine if a particular software technology pattern is suited for your business solution. It is best to identify network contention limitations during the design process. Too often we see clients deploy solutions for client locations with insufficient network infrastructure. These mistakes can be avoided by completing a network suitability analysis as part of your system architecture design.
The following video provides an overview of the CPT Calculator network traffic functions. The video also provides an overview of the CPT Design User Requirements Module and shows how the CPT Design completes the network suitability analysis.
Network Communications 32nd Edition
Network Communications 31st Edition
Network Communications 30th Edition
Network Communications 29th Edition
Network Communications 28th Edition
Network Communications 27th Edition