性能测试之-------网络瓶颈

上一篇 / 下一篇  2012-08-31 11:14:22 / 个人分类:IT英语

Most often it is not necessary to go about doing something specifically such as a network test per se. I would recommend engineers to perform. their routine test cases on the AUT such as load test, stress test, endurance test etc. with client specified workload, but during the course of these tests pay attention to the network monitoring part of the test endeavor. There are certain servers monitoring tools specifically meant for monitoring network resources(netstat and network protocol analyzers(wireshark)) which I would recommend you to use other than any load testing tools.

On the other hand if the client has a scenario where there is a massive batch run or backup software causing huge amount of data moving across the network for long hours then I would recommend you to go about performing network tests specifically to emulate such scenarios.

For a network test you can have a Goal Oriented scenario setup with a certain Throughput as the target. Monitor the throughput and time to first buffer graph to find network related issues along with netstat and network protocol analyzers.

For a LoadRunner user the important counters which can be used are Total Bytes counter/sec, server bytes/sec, connections established counter; but note that it is even more important to understand the usage of these counters in identifying bottlenecks. Go through the documentation and get a clear understanding of these counters up front. On a high level be it LoadRunner or IxChariot or say any tool that you use to monitor and collect server metrics, the most important metric you have to make sure you have are:
1. Data Volume: Amount of data sent across then network.
2. Throughput: The speed at which data is sent through the network.
3. Data error rate: Large number of network errors that require retransmission of data will slow down throughput and degrade application performance.

When you’re trying to break down a performance bottleneck the first step you will have to make is to write down a matrix with traffic type against layer/tier. This will help you isolate the network which is causing the problem and henceforth to tune it without having to exercise dart-throwing as you struggle to understand your web site bottlenecks.

Example:
Client-Server communication:
Traffic:
-User HTTP requests
-Server HTML responses
- HTML page elements, such as gifs, jpegs, flash objects
etc..

Server to server communications (Middle tier)
Traffic:
-HTTP session data sharing within a cluster
-Application database transfers
-Traffic to services node (web services)
-Traffic to mail or messaging services
DNS traffic. etc…

Backend communications
Traffic:
-Databases transfers
-Database to application traffic
Etc.

During the analysis process, isolate the network portion which has the problem from the above layers and then find a way to troubleshoot the issue by correlating with the type of traffic which is observed in that layer.

Commonly observed network performance bottlenecks:
1) Faulty network component causing packet storms in the network.
2) Improperly configured NIC cards: Especially a node involving Multiple NICs can have a problem such as improper binding of NIC cards causing few NICs to be over utilized and others underutilized.
3) Improperly configured Load Balancer; Example: Affinity routing aka IP routing the requests to servers when the requests are coming from behind a proxy.
4) Insufficient bandwidth (This problem can be easily detected from the throughput graph when it becomes flat.)
5) Firewall component can be a major performance bottleneck: I would recommend engineers to first test the application system without firewall so that at least one variable is avoided.
6) Duplex mismatch: This problem occurs when one of the two communicating element is operating in full duplex whereas the other is operating in a half duplex mode. Unlike full duplex communicating element the half duplex element can either send or receive data packets but cannot do both together hence causing slowness in overall transfer speed due to heavy packet loss.
7)Using excessively chatty protocols: Too many handshake signals are definitely an overhead not just in the application front but also in the network resource front. A protocol analyzer can be very handy to detect such issues.
8)Too many network hops or links between source and destination negatively affects the Round Trip Time(RTT) of packets.
9)Propagation delay, i.e. when distance or Path between client and server is huge. Packet latency can be high in such situation. Regional servers can help in eliminating the problem.


TAG:

 

评分:0

我来说两句

Open Toolbar