5) Incorrect filters–either Capture or Display
An important concept here is that filters add nothing–they only remove–they only filter out. When you say that you are “filtering for” what you mean is that you are “filtering out” everything else. This isn’t just semantics as understanding this perspective is critical to success.
Capture Filters:
Capture Filters are irreversible. If you filtered out something that you need to see–you just aren’t going to see it. There is no second chance without running the test again.
Capture Filters determine what is allowed in the Capture Buffer. If the data is there to see–great. If you filtered what you need out–you can’t change the filter after the fact. A very experienced Protocol Analyst may notice the problem by seeing anomalies that amount to the shadow of the missing data–but most will not be able to tell. And, of course, even if you can tell–you still have to re-test.
This might lead you to think that you should not use Capture Filters–and that is half true. If you don’t really need them–don’t use them. However, if you are drinking your packets out of the Fire Hydrant–you have no choice. Under those conditions the data will fill up your Capture Buffer is less than a single second.
Another point is that they should be consistent within a Test Design. If they vary too much, they will create false differences that can easily lead the Network and Application Performance Analyst or Protocol Analyst astray.
Monitor Filters:
Monitor Filters are forgiving. They work the same way–in that they filter out, not in. However, you can change your mind. The data is in the can (trace file) and it is only a matter of changing the filter to see what was filtered out the last time. Many times I am stumped and then have an idea–go back and change my Capture Filters–and bam! There is the answer. The point is–incorrect Monitor Filters will just as easily lead you astray–but you still have the opportunity to find your way back since the data is still there.
Again, this might leave you thinking to avoid Monitor Filters. Don’t even consider it. Removing irrelevant packets is required to properly measure distinct conversations and search for anomalies. In fact, understanding proper filtering is what using the packet-sniffer software is all about.
6) Lack of understanding the Packet-Sniffer’s CURRENT settings
Monday, you created a Capture Filter and left it as the default. Friday you need to capture a trace file and click on Capture. Various people perform their roles in the test and you save the trace file. Everyone goes home, back to their main job function or to bed. Then you look at it and discover that you didn’t realize that the old Capture Filter was still in effect! Why? You altered the Default Capture File instead of creating a new one. Your Trace File is useless.
Always remember to review ALL settings before beginning a test. Additionally, run a practice test to make sure all filters and setting are as they should be.
Sometimes the error you discover is that you were given an incorrect IP address and that you never would find what you are looking for from the IP address from which you are capturing packets. That is a GOOD finding. It means someone’s diagram is incorrect. It also means you prevented a useless round of testing.
7) Lack of test controls.
Like any proper experiment, a performance or application test requires a control group and controlled data for all groups. If it was a pharmaceutical test you might have a group with a placebo. In our field we need to create a “BESTline” first. A “Bestline” is not a baseline.
Here is an example.
You have a Client in Singapore and a Server in New York City. The client is Singapore takes 40 milliseconds to execute a transaction and European clients only need 30 milliseconds. Singapore, although farther away, has a faster connection and is expected to get it done in the same time as Europe. What now? Take a BESTline. Use a client in New York City running the same transaction in the same way on similar equipment on the same server as the other two tests. You may discover that it still takes 25 milliseconds! This may due to various issues in the Data Center, Server or PC itself, 25 milliseconds is the fastest it goes!
This means that the first 25 milliseconds have nothing to do with the transport distance or speed. It DOESN’T mean that you have to accept those 25 milliseconds. There is a great deal that can be done about it. However, it is not the network and you now know you have to focus on the Server, PC, Data Center and other components.
Such controls are easy to do–yet seldom done. That common error results in many false leads and false errors as well as lost time and money.
There are many more common mistakes……but they are the topic of different articles on http://www.InterpathTech.com.
