Network and geography

The network includes:

• Communication with mail servers
• Communications between Traveler servers in an HA environment
• Communications with the DBMS server
• Communications through any firewall, load balancer, proxy server, and so forth.
• Communication over the internet to mobile devices.

Unfortunately, network performance is difficult to troubleshoot so it is important to engage your network team early in the planning process to ensure maximum performance of your Traveler environment. When reviewing the network architecture, keep the following best practices in mind:

• In general, geographical proximity improves network performance. The closer all the components are the faster the network is between them. In a perfect environment, all components of a Traveler environment are in the same lab on the same subnet.
• When possible, set up Traveler environments that are geographically close to your user base. In general, the closer your users are to your Traveler environment, the more responsive the service is.
• When setting up the Traveler environment, test the network speeds between the Traveler server and the mail servers. Often the mail servers are geographically separate from the Traveler environment. Though not recommended, this certainly can function well. However, it’s important to test the network speed between the environments and make improvements as necessary. In general, a ping time of <50ms is desirable for communication between Traveler and mail servers.
• Any component in front of the Traveler environment (firewall, load balancer, proxy server, and so forth) should support long-running HTTP connections without data packet modification.
• Test the network speed for connections points between your user base. Not all networks are the same. Often users in one geography have a slower network than those in another. Being aware of these differences can help you to plan your environments accordingly, or at least be prepared to handle service calls for slow response times.
• In general, don't distribute any part of the core Traveler environment across different geographies for the purpose of disaster recovery. There are some customers who have successfully done this, but it requires high-speed, dedicated network paths between the various components which can be costly and often are problematic. In most cases, its more cost effective to maintain a separate 'backup" environment that users could switch to in an extended outage, even if this means they have to resync their data to their mobile devices.