Problem Statement:
You are experiencing “slow” response times for the web application
Background:
From the user's perspective, a few different things can affect the speed of a web app:
Speed of the server/application (Intelliquip controls)
Speed of the network:
Local connection speed (user's responsibility)
Number of "hops" to the server (a.k.a., how far the packet has to travel between
client and server. Across the city or across the world?) (Intelliquip can control by adding regional servers.)
Size of the payload (a.k.a.,
how many bytes are being downloaded, for example a large PDF file? (Intelliquip
controls, but user needs to be understanding of large PDF downloads taking
extra time
Common Problems:
Apparent “slowness” with a web app is often a result of a slow connection, in which case all or most websites are slow. This is totally under the user's control, and Intelliquip cannot help remedy this situation.
Special Case: If you are in China, and you are trying to reach servers outside of China, the government is likely throttling -- or even blocking -- access to certain sites. (The Chinese Government is trying to prioritize giving China-hosted websites preference over foreign-hosted websites.)
Troubleshooting Steps:
If you have an IT or Network technical support person at your work, this would be a good time to include them in your process!
Step #1
Ensure your local network performance is adequate:
Run a bandwidth tester. We use http://www.speakeasy.net/speedtest/
Pass: Any download/upload speed over 1.0 Mb/s is acceptable.
Continue to Step #2.
Fail: Speeds less than 300 kb/s will generally cause poor performance.
Remedy: You will need to improve your network connectivity. You can continue to look at next steps below, but there is very little that will help.
Step #2
Check your browser settings (each browser/operating system may have slight variations, but you can always search for help). Read more about proxy settings here:
Chrome Help page.
Windows 7/Internet Explorer 9 page.
Check your proxy server to make sure the settings are correct. The proxy needs to be setup to run/support HTTP 1.1
IE will look something like this:
Chrome, you will find the settings under “Advanced”
Which may direct you to your computer's settings:
The intelliquip.com domain should be added as an exception from caching at the proxy server
Step #3
Check on access to specific Intelliquip servers from your desktop:
Windows
First, open up a “terminal” (in Windows, this means Start | Run | Command) Run the following commands, adding your appropriate domain:
ping your_domain.intelliquip.com
tracert your_domain.intelliquip.com
Open the terminal window's “menu” by clicking the icon in upper left corner.
Choose Edit | Select All
Choose Edit | Copy
Mac OS X
First, open up a “terminal” (Command( )-space, enter 'terminal' into Spotlight). Run the following commands, adding your appropriate domain:
ping -c 5 your_domain.com
tracert your_domain.com
From the terminal window:
Select All: -A
Copy: -V
Send the Results
Send this info to your IT support person and to your Intelliquip contact by pasting the results (that you just copied, above) into an email.
Interpreting Results
Traceroute will tell you how many routers your packets travel through, and how long it takes for them to travel between routers. If the routers have DNS entries, traceroute will list the names of the routers, their network affiliation and geographic location. For example, here we “ping” a server in India, halfway around the world from the eastern United States:
$ traceroute your_domain.intelliquip.com
Traceroute has started
traceroute to your_domain.intelliquip.com (115.113.144.122),
64 hops max, 72 byte packets 1 10.0.0.1 (10.0.0.1) 4.010 ms 1.110
ms 1.077 ms
2 68.82.202.1 (68.82.202.1) 31.589 ms 23.573 ms 31.034 ms
3 te-1-2-ur01.milford.pa.panjde.comcast.net (68.87.215.49) 10.735
ms 10.516 ms 10.181 ms
4 te-1-1-ur01.franconia.pa.panjde.comcast.net (68.86.208.170) 11.209
ms 10.426 ms 11.235 ms
5 xe-7-1-5-0-ar03.norristown.pa.panjde.comcast.net (68.86.153.181)
19.654 ms 13.936 ms
10.583 ms
6 ae-1-0-ar03.ivyland.pa.panjde.comcast.net
(69.139.193.245) 13.041 ms 13.641 ms 13.483 ms
7 pos-3-15-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.95.1) 16.718
ms
pos-3-14-0-0-cr01.newyork.ny.ibone.comcast.net
(68.86.95.169) 18.747 ms
pos-3-12-0-0-cr01.newyork.ny.ibone.comcast.net
(68.86.95.161) 18.686 ms
8 pos-1-0-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.86.42)
20.775 ms 19.859 ms
15.914 ms
9 ix-0-1-1-0.tcore1.nto-newyork.as6453.net
(209.58.26.117) 19.617 ms 16.946 ms 16.754 ms 10 63.243.128.38 (63.243.128.38)
379.074 ms 349.467 ms 307.153 ms
11 if-9-2.tcore2.wyn-marseille.as6453.net (80.231.200.13) 307.330 ms 429.389
ms 308.746 ms 12 if-2-2.tcore1.wyn-marseille.as6453.net (80.231.217.1)
212.404 ms 214.495 ms 310.568 ms 13 if-9-5.tcore1.mlv-mumbai.as6453.net
(80.231.217.18) 307.294 ms 431.301 ms 306.769 ms 14 180.87.38.6 (180.87.38.6)
306.776 ms 205.192 ms 208.327 ms 15 172.25.80.53 (172.25.80.53) 371.710
ms 270.629 ms 405.495 ms 16 172.25.83.142 (172.25.83.142) 307.167 ms 291.686
ms 307.121 ms 17 59.162.51.6.static.vsnl.net.in (59.162.51.6) 615.827
ms 307.109 ms 307.210 ms 18 115.113.144.122.static-pune.vsnl.net.in (115.113.144.122)
307.130 ms 307.117 ms 307.218 ms
Check for times between hops that are greater than 200 ms or that return asterisks *** which indicate that your request has timed out.
In the above example, you can see that once the message “hopped” from New York (USA) to France (steps 9, 10, 11), the times are between 200-400ms.
When using this server app in India from the eastern USA region, it is quite slow -- even on a good network. This is due to the number of network hops, and the fact that some of them are slower than ideal. There may also be intermittent packet losses, further slowing down the apparent speed of the application (we will show you how to test for packet losses below, and show you examples of good and bad network access statistics).
Pass: If you have average (Avg) times < 200 and if you show very little data loss, you can be assured the network “distance” and number of hops is not an issue.
Fail: If you have many average times > 200 and/or if you have a great deal of data losses along the hops, it is likely that your “distance” to the server is too great.
Remedy: To reduce the number of network hops, it generally requires locating the application server closer to the geographic region in which it is being used.
More Information
You can read a good explanation here: http://kb.iu.edu/data/aihy.html Here is another link (Windows) that describes all the options if you want to know more details: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/tracert.mspx?mfr=true
Extended Testing/Data Loss
Another Windows/DOS command to try is pathping, which can be used like this:
pathping your_domain.intelliquip.com
As described here, pathping provides information about network latency and network loss at intermediate hops between a source and destination.
On the Mac, you can find a wonderful set of diagnostics under Application | Network Utility. But to run the equivalent pathping utility, you need to install “MTR”. MTR probes routers on the route path by limiting the number of hops individual packets may traverse, and listening to responses of their expiry. It will regularly repeat this process, usually once per second, and keep track of the response times of the hops along the path.
Read more about MTR here : http://en.wikipedia.org/wiki/MTR_(Software)
brew install mtr
brew info mtr
(Follow instructions to either run with sudo, or modify the mtr permisions)
/usr/local/Cellar/mtr/0.82/sbin/mtr -c 200 -r your_domain.intelliquip.com
HOST: JonKern.local Loss% Snt Last Avg Best Wrst StDev 1.|--
10.0.0.1 0.0% 200 1.8 1.6 1.1 15.8 1.4
2.|-- 68.82.202.1 0.0% 200 21.9 26.9 10.6 43.9 5.1
3.|-- te-1-2-ur01.milford.pa.pa 0.0% 200 11.9 16.7 9.6 751.5
52.5
4.|-- te-1-1-ur01.franconia.pa. 0.0% 200 12.4 13.2 9.9 193.8
13.1
5.|-- xe-7-1-5-0-ar03.norristow 0.0% 200 12.3 14.0 10.2 59.9
6.1
6.|-- ae-1-0-ar03.ivyland.pa.pa 0.0% 200 13.6 20.8 11.9 142.1
21.7
7.|-- pos-3-13-0-0-cr01.newyork 0.0% 200 16.4 19.1 15.2 32.3
2.5
| `|-- 68.86.95.161
| |-- 68.86.95.1
| |-- 68.86.90.65
| |-- 68.86.95.169
| |-- 68.86.94.233
8.|-- pos-1-0-0-0-pe01.111eight 0.0%
200 21.7 19.3 15.7 27.9 1.9
9.|-- ix-0-1-1-0.tcore1.nto-new 0.0% 200 21.0 17.7 14.4 53.5
4.3
10.|-- 63.243.128.38 0.0% 200 230.3 222.2 212.3 306.9 11.8
11.|-- if-9-2.tcore2.wyn-marseil 0.0% 200 211.7 214.7 210.2 268.0
7.9
12.|-- if-2-2.tcore1.wyn-marseil 5.5% 200 217.1 215.6 210.3 259.2
8.2
13.|-- if-9-5.tcore1.mlv-mumbai. 0.0% 200 208.5 216.4 207.7 279.5
10.6
14.|-- 180.87.38.6 0.0% 200 208.2 208.4 204.0 266.3 9.0
15.|-- 172.25.80.53 0.0% 200 214.4 221.3 213.7 304.5 14.3
16.|-- 172.25.83.142 2.0% 200 217.7 225.0 215.3 417.7 30.7
17.|-- 59.162.51.6.static.vsnl.n 0.5% 200 211.6 230.8 209.6 585.5
56.3
18.|-- 115.113.144.122.static-pu 0.5% 200 218.8 221.1 218.7 236.6 2.2
You can see in the above results that pinging a site halfway around the world shows some data losses. These are often a result of path congestion. Note: the network transport protocols account for packet losses, and packet resends are automatic to ensure the full message was properly retrieved. However, as you might conclude, this also causes a “slow down” in message transmission, as packet retries take time. By contrast, here is a site from within the USA:
$ /usr/local/Cellar/mtr/0.82/sbin/mtr -c 200 -r
xxx.intelliquip.com HOST: JonKern.local Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.0.0.1 0.0% 200 1.2 2.1 1.1 20.0 2.7
2.|-- 68.82.202.1 0.0% 200 28.4 26.3 11.5 47.8 5.0
3.|-- te-1-2-ur01.milford.pa.pa 0.0% 200 13.8 12.2 9.2 98.3
6.5
4.|-- te-1-3-ur01.franconia.pa. 0.0% 200 10.6 12.9 9.8 144.5
9.7
5.|-- xe-7-1-4-0-ar03.norristow 0.0% 200 14.7 17.6 10.4 59.6
6.8
6.|-- ae-1-0-ar03.ivyland.pa.pa 0.0% 200 12.0 19.5 11.8 147.4
19.2
7.|-- pos-3-13-0-0-cr01.newyork 0.0% 200 18.5 19.4 14.9 49.7
4.0
| `|-- 68.86.90.65
| |-- 68.86.94.233
| |-- 68.86.95.1
| |-- 68.86.95.169
| |-- 68.86.95.161
8.|-- he-4-9-0-0-cr01.ashburn.v 0.0%
200 21.5 22.0 18.0 36.9 2.8
9.|-- he-4-9-0-0-cr01.56mariett 0.0% 200 35.2 36.5 31.8 103.7
5.7
10.|-- pos-1-8-0-0-cr01.dallas.t 0.0% 200 54.4 56.6 51.7 95.4 5.1
11.|-- pos-0-5-0-0-pe01.1950stem 0.0% 200 55.5 56.4 51.5 87.5 4.2
12.|-- rackspace-bbr.dfw1.comcas 0.0% 200 53.4 53.4 51.1 67.7 2.2
13.|-- corea.dfw1.rackspace.net 0.0% 200 56.1 55.5 52.8 71.9 2.9
14.|-- core3.dfw1.rackspace.net 0.0% 200 56.2 56.3 52.8 77.1 3.6
15.|-- aggr107a.dfw1.rackspace.n 0.0% 200 55.8 56.4 52.9 69.5 2.6
16.|-- 174.143.15.12 0.5% 200 54.5 55.0 52.7 83.3 3.3
Note how the average times are all below 60ms, and there are almost no packet losses. The above illustrates web site access with excellent characteristics.