How to Report a Performance Problem

As you investigate a network performance issue, whether as a network user, support person such as a systems or network administrator, or as a network performance expert, at some point you may decide that the problem at hand cannot be solved without outside help. Leaving aside for the moment the problem of whom to turn to, here ara a few hints about how to report a performance issue.

The recommendations in this section are derived from experience trying to help users with performance problems, notably things that are easily forgotten and lead to e-mail round-trips. While supporters (such as PERT teams) will simply ask iteratively for information that is missing during an investigation, it is almost always better to include as much information as possible up front, in order to speed up the process and to make documentation of the issue easier. If all relevant information is included in a few e-mails, it also becomes easier to ask a third party for help.

Describe the performance experienced

Try to describe clearly, and if possible quantify, how the application performs. Be clear about metrics and units, in particular when stating bandwidth and throughput measurements (bits vs. bytes per second). State how you did the measurements. Cut-and-pasted text from a terminal session with the actual application run and/or measurements is always appreciated. If such text cannot be provided, application screendumps are also useful.

Describe your performance expectations

It is very important to tell how your observed performance derived from your expectations, and how far performance should improve until you would consider the problem solved. If performance has regressed from past performance, it is very useful to state past performance numbers, if possible in the same manner as described above for current performance. But past performance is not sufficient; you should always state your performance requirements.

Describe your endpoints (hosts etc.)

You should provide as much information about the hosts and network attachments participating in the application. Often you will only control one side of the application (e.g. when you complain about downloading performance from a popular Web server), but when you know the people at the other end(s), it is extremely helpful if you can ask them for such information too.

Vital information about an endpoint includes:

Its IP address. On a Unix system, ifconfig -a is a good way to provide address information for all interfaces. On a Windows system, ipconfig can be used to generate similar information.

The hostname. While less important than the IP address, it makes it easier to refer to systems when communicating.

Operating System information. On Unix systems, uname -a provides summary information about the system version. Other systems typically have an information box that will provide OS version information.

Application(s) used, including version information.

The exact hardware configuration used is often hard to retrieve, and usually only little of this is relevant. Include what you know and what you think might be important. One aspect that is often important is the type of Network Interface Card (NIC). On Unix systems, lspci -vv might be usefull, it provides information about all PCI buses in the system and all devices connected to them.

This brings us back to the network attachment (the IP address is part of that, too.) Cut-and-paste output from traceroute is always very welcome. If possible, provide traceroutes in both directions, from your host towards the other relevant host(s), and if available, traceroutes back from the other host(s) to yours. In the campus network environment, try to find out about the structure of your local area network (switched network), and the use of devices such as firewalls, bandwidth management/rate shaping tools and similar equipment at the border between the site and the external network. You will typically have to ask your friendly local networking people, but this kind of information has proven extremely important in the past, and it usually cannot be derived from traceroute output.

-- SimonLeinen - 12 Apr 2006
-- BartoszBelter - 13 Apr 2006

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2006-04-13 - BartoszBelter
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2004-2009 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.