1

From client pc to server (Windows Server 2008), the WAN connection is using 2 x 2 MBps E1 link. 

1       <1ms    <1ms   <1ms             10.101.7.254
2        4ms    15ms    4ms             10.255.0.254
3         *      3ms    3ms            192.168.243.251
4         *      5ms     *             192.168.242.253
5        6ms      *     6ms             10.100.101.252
6        5ms     5ms    5ms             10.100.10.201        (SERVER)

Client pc is experiencing lagging issue when accessing to the web application (Pyramid application) hosted at server by using IIS port 80. However, I found out that the connection is smooth when using Waitress WSGI server port 5432.

We can notice that TIMEOUT is happening on 3 of the hop. This could cause the system to be slow in response. I noticed that it's quite frequent to receive response timeout in the PING request.

Network Team mentioned that the traceroute shows the expected network performance. 5ms for WAN link is way below the latency requirement. Time out in traceroute is normal in dynamic routing due to the dynamic paths within the WAN cloud, and so the result is expected and is not a network issue.

For this scenario, I not really sure that is application design problem or network problem. Can anyone pls kindly advise me how can I figure the problem? Much appreciate for any reply.

SƲmmēr Aƥ
  • 113
  • 4

2 Answers2

2

Network Performance Analysis: You're doing it wrong.

Tracert and Ping ARE NOT network performance analysis tools. They are tools for tracing the route to a host and for testing basic connectivity to a host.

The problem with using tracert as a network performance analysis tool lies in the fact that tracert sends ICMP packets TO each hop in the route. Tracert isn't testing "real" traffic THROUGH the route. As such, each hop may choose to ignore your ICMP traffic or may choose to give it low priority, which gives you results like you see in your tracert test.

What you need to do is to test the performance of REAL traffic THROUGH the route. You can do this with tools like iperf or Qcheck.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
1

You seem to have latency and drop rates confused. Latency is the amount of time it takes a packet to traverse the network. Drop rates are the percentage of packets that are never delivery (for various reasons). Your latency seems to be very low, I don't see why you mention it at all.

You seem to have packet dropping problem, but you haven't presented conclusive information. Run ping -n 1000 -w 100 10.100.10.201 and see what the results are.

Some packet loss is to be expected in large networks, but not much. If you're experiencing more than 1% packet loss there's a problem. Also, don't use the word "cloud", it means nothing.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • thanks for your reply. I am not able to test the ping right now. Just wanna to know could it be caused by application layer also? Network Team mentioned that requests timeout is normal as they set each 30 ping requests will be request time out once because of security issue. – SƲmmēr Aƥ Dec 03 '12 at 14:27
  • The problem could be anywhere. If your network team is unwilling to prove that their network is working correctly then you will not be able to troubleshoot the problem. Also, if you know 1 out of 30 packets will be dropped "for security", then you should still receive the other 29 normally. Ping should still work. – Chris S Dec 03 '12 at 14:33
  • but then one thing I wondering could it be caused by particular traffic from port 80 being filtered or blocked? since other port work fine. – SƲmmēr Aƥ Dec 03 '12 at 14:55
  • There's really no point in trying to troubleshoot anything unless you've got a solid foundation. – Chris S Dec 03 '12 at 15:09
  • If port 80 traffic was being blocked then it wouldn't work at all... ever. – joeqwerty Dec 03 '12 at 15:18