Updated: Sep 21, 2018
by David Hallberg
The first step for RHOs in diagnosing performance issues is to verify whether you still can actually reach the Millennium Application nodes from your network. You determine your connectivity by running the ping utility. The following steps will help you determine if you can ping the backend nodes from your help desk.
1. Start by finding the name of the Millennium nodes.
There is a utility called ddirdump.exe that should be on a local install of Millennium (a fat client). When you run this utility, you will see output analogous to this:
This result shows that the domain “prod” runs on two nodes, which are named “hnaa” and “hnab.” You will use these names for the ping command.
2. From a DOS prompt or CMD prompt, enter “ping -n 100 <node name>”. If, for example you enter “ping -n 100 hnaa”, you will see 100 lines of output analogous to this:
3. Sometimes the default size of the ping packet can get through but larger packets cannot. To test the speed of a larger packet, run a ping like this: “ping -n 100 -l 1500 hnaa” (where the -l is the letter “l” as in lima). You will see 100 lines of output analogous to this:
This output shows that basic connectivity is up and running between your facility and the location of Millennium. If the “time=XXms” is greater than 100, you are going to have performance issues. Optimal performance in an n-tier client/server architecture like Millennium would be less than 10ms. In the RHO setting you will rarely, if ever, be able to achieve a 10ms round-trip time. A more normal latency (the time it takes to go from your facility to the RHO facility and back) is 30-40ms. If you are not achieving this, you need to work with your RHO provider and your telecommunications provider(s) to improve the latency.
There should be no timeouts or host-unreachable messages. If there are, this indicates you have a stability problem in the network between your PC and the Millennium Application node(s). If you have either of these messages, you want to use the trace route tool called tracert (for those running on a Microsoft Windows PC or server) and perform the following:
From a DOS prompt or CMD prompt, enter “tracert <node name>”. If, for example, you enter “tracert hnaa”, you will want to see output analogous to this:
C:\> tracert hnaa
Tracing route to hnaa [172.16.0.1]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 126.96.36.199
2 <1 ms <1 ms <1 ms 188.8.131.52
3 <1 ms <1 ms 44 ms hnaa [172.16.0.1]
It’s best to run this utility prior to experiencing performance issues, so you know the normal network path. This example of a successful tracert shows very little latency until the last router (the RHO router), which indicates the majority of the “wait” is on the RHO provider.
If, however, your tracert looks like the example below, it means your default router is not able to send your network packets to the Millennium Application node.
If the “Request timed out” came from the location of the Millennium Application node, it means you cannot get from the RHO provider’s router to the node. It’s a connectivity issue that manifests itself as a performance issue. The good news is your network team can call your RHO provider to resolve it.
The following free tools from Microsoft Windows offer ways to verify if there is a problem between your organization and the RHO provider: