In our previous network latency blog, we looked at the quantitative impacts that network latency to the database can have on an ArcGIS system. But what about latency at other tiers?
Network latency can happen anywhere distributed system components exchange data. This includes when a client, like ArcGIS Pro, connects to the services tier, like ArcGIS Enterprise, for tasks like editing data. As organizations continue to shift to the cloud and support a distributed workforce, they must employ thoughtful design choices to ensure they deliver not only functional, but also highly responsive experiences for end-users.
- Learn more about network latency and its impact on ArcGIS systems here.
- Learn about ArcGIS Pro in virtualized environments here.
How to reduce latency between clients and other system components
In cloud-hosted environments, understanding how network latency impacts users, and mitigating those impacts through careful design, is critical to maintaining performance and usability. You can reduce network latency between clients (e.g desktops, laptops, mobile devices, and remote desktops) and other system components in several ways. While not comprehensive, this list highlights some key considerations:
Reduce physical distance between users, desktops, ArcGIS Enterprise, and the enterprise geodatabase.
Physical distance between users, the clients they access, and the services they use increases latency and can create lag that’s detrimental to user efficiency and experience. Consider:
- Deploying system components in cloud regions as geographically close to users as possible.
- Multi-region deployments or hybrid architectures for global teams.
Mitigate VPN impacts when possible
VPNs can introduce noticeable perceived latency that appears as lag to end users in several ways. For example, they:
- add encryption overhead, which adds processing time
- may route traffic inefficiently, often through centralized gateways or data centers
- often throttle bandwidth, slowing data transfer rates
To help mitigate some of these impacts, consider:
- Choosing a VPN that provides minimal throttling or unlimited bandwidth and uses smart routing.
- Configuring VPN gateways closer to users to reduce unnecessary hops.
- Testing performance with and without a VPN to identify bottlenecks and adjust policies accordingly.
Leverage cloud services
Major cloud providers offer services to route user requests to the nearest edge location, onboarding traffic to their high-speed networks. This can help reduce latency between the client and services tiers through faster and more efficient networking, similar to taking a freeway between two cities rather than local roads.
Choose or advocate for the right remote display protocol and VPN
Choose the optimal client connection for your organization’s needs. For example, RDP (Microsoft’s Remote Desktop Protocol) provides a general-purpose protocol commonly used for remote access to Windows environments. Meanwhile, the AWS DCV remote display protocol is often used to access AWS instances.
However, if users connect via remote desktop in conjunction with a VPN, latency will likely increase due to VPN overhead. This could make even simple UI interactions seem sluggish. VPNs provide significant security benefits. Still, it’s important to measure and optimize the latency they introduce so users can be productive, as well as secure.
Optimize client internet connections
Remote users connecting to cloud infrastructure can also experience poor performance as a result of their own internet connection. For example, limited bandwidth, excessive network hops, or otherwise slow internet speeds can delay map rendering and data transfer.
- Encourage users to connect via wired or high-speed networks when possible.
- Optimize services by using vector tiles, filtered feature layers, and scale-dependent rendering to reduce payload size.
- Configure offline maps for field workers that have poor connectivity
- Monitor client-side performance and optimize connectivity where possible.
Quantifying the impact
We know all these design and configuration choices can impact performance and user efficiency – but by how much? Well, let’s review some results from a recent trouble-shooting activity. The measurements shown in the graphics below help quantify how significantly these choices affect the system’s behavior and user experience.
The green lines represent connections between components inside the Virtual Private Cloud (VPC). They have very low latency because they sit close together, physically and on the network. Each diagram highlights one of the three scenarios we tested to understand the network latency between different points. From there, we identified the best path for mappers to perform their work for this organization.
Scenario 1 : remote workers connect with VPN to a virtual desktop that is collocated with ArcGIS Enterprise in the VPC
Workers connect to virtual machine instances with AWS DCV from their remote offices and laptops. They establish a VPN connection and launch ArcGIS Pro on a virtual desktop to edit map features. Network latency between the virtual desktop and ArcGIS Enterprise stays low – less than 2ms. And the latency between ArcGIS Enterprise and the geodatabase drops below 1ms. However, latency up to 220ms between the user and the virtual desktop creates a serious problem.
This latency is caused by the geographic distance between the user and the VPC, the VPN, and the user’s Internet provider (the number of hops in the route and the speed of the service). The result is graphics-related lag, like a sluggish cursor that can’t quite keep up with the user. The system overall is performant because components within the VPC have very low network latency. However, the graphics- related lag impacts user experience and productivity. And because user efficiency impacts the bottom line, helping users be productive is in everyone’s best interest, and ultimately helps maximize return on investment.
Scenario 2 : remote workers connect to desktops in the office, with ArcGIS Enterprise components deployed in a VPC
Workers use a VPN connection from their laptops and RDP into desktops located in the corporate office, launch ArcGIS Pro, and then connect to ArcGIS Enterprise services in the cloud. This scenario produces some latency between the remote laptop and the office (75ms) as well as between the office and ArcGIS Enterprise (55ms).
This scenario has less total latency than scenario 1 (about 130 ms vs 220 ms) because the worker sits closer to the corporate office (which has a better connection to AWS). Overall user experience may be better because the users enjoy more responsive mouse clicks and movements. However, ArcGIS Pro may take longer to process some requests waiting for data transfer. But, that processing isn’t experienced by the user in the same way (e.g screen latency or mouse sluggishness.) Any perceived latency in this scenario likely results from processing slowness due to the data transfer distance.
Scenario 3 : remote workers connect directly to a virtual desktop that is collocated with ArcGIS Enterprise in the VPC
Workers connect directly to virtual machine instances (no VPN) with AWS DCV from their remote offices and laptops and launch ArcGIS Pro on a virtual desktop. Latency between the user and the virtual desktop, which ranged from 69-151 ms depending on which user was testing, created the problem here. Eliminating the VPN reduced network latency as compared to scenario 1, but not enough to eliminate lag for all users. This scenario is impacted by the geographic distance between the remote office and the virtual private cloud, as well as each individual user’s Internet service. Ultimately this is not an acceptable solution in this situation because there is no VPN, which is necessary for security purposes. Further, this scenario didn’t produce consistent results for all users.
Tools
To monitor and evaluate network latency at the client tier, you need to collect certain kinds of measurements. For example, in this case we collected telemetry using the PsPing utility which measures network performance, including bandwidth and latency. We also used tracert (trace route), a Windows network diagnostic command-line utility, which maps the path data packets taken from a client to a destination.
Summary of results
- The mapper only had acceptable latency when going through the corporate office. This result was impacted by the individual users’ home internet provider – some testers had slightly better results.
- The VPN added up to 70ms to the network latency as shown by the difference between scenario 1 and scenario 2.
- The path of the virtual machine instance to ArcGIS Enterprise through to the enterprise geodatabase is very fast (~2ms), indicating the bottle neck is in the connection to the virtual private cloud.
Recommendations
Whether presenting as graphics-related lag or slower data processing, high network latency negatively impacts user experience, their ability to work productively, and consequently, the bottom line. Therefore, doing what you can to reduce network latency across a system’s tiers is a worthwhile pursuit.
While what we’ve shown here is just one possible deployment scenario, we can gather some broadly applicable insights to help you make design decisions that reduce network latency and provide a positive end user experience:
- VPNs, while often necessary for security, can cause significant latency, especially if they route inefficiently or throttle bandwidth. You have many choices, and testing might show that one works better than others in your situation.
- Even without a VPN, performance is dependent on the internet connection speeds of the remote workers.
- Distance between system components should be minimized whenever possible.
- With a distributed workforce, several factors need to be considered, including:
- The distance between the worker’s device and the remote desktop (largely impacting UI interactions)
- The distance between the machine running ArcGIS Pro and ArcGIS Enterprise (largely impacting data transfer and processing).
Article Discussion: