Three steps for making the right diagnosis
Measurement in an ICT network is a must when solving network performance problems. This can be done in many ways and you really don’t need to be an expert to make analyses. Which tools do you need in which situations and why? And what does it yield?
Why measure?
Measuring is, in my opinion, essential in many cases to reduce diagnosis time in network problems. If a problem is solved within 30 minutes, the need for measurement is not so great. However, practice is often different. In many cases it is an accumulation of events and consequences on a situation. Without measuring, it becomes almost impossible to figure out why something is not working properly in a technical chain. Only through trial and error can you arrive at a solution. Therefore, to make a good problem diagnosis, it is necessary to collect facts. Gathering the facts requires the right tools. Often the IT department already has resources in place to measure. These can include free software programs for reading equipment, but sometimes complete End-to-End Performance solutions.
Two ways of measuring
Roughly speaking, there are two ways of collecting data. The first way is to collect statistics. The second way is to measure data flows in networks. This can be done by measuring in protocols where insight is gained into where the delay is, what the quantity of data is and why something is not working well. This is because the protocols contain information about the completion of tasks. For example, why can’t a file be opened? The user receives a notification, but how and why is unknown. Measurement then offers a solution by providing insight that, for example, the server buffers are not adequate.
Example
A user complains that entering an order takes a long time. The wait is for the cursor to move between the program’s lines and entry fields. Diagnosing without measuring is very difficult. Is it due to the workstation? Is Windows causing the problem? Is it in the network? Is the server slow? Is the problem in the application on the server that needs to collect data on the other SQL server? In short, you have no idea where the cause of the problem lies. By measuring, you can quickly gather information in the above chain, rule things out and look for the root cause.
Three steps for making a diagnosis
However, it is important to do some mapping. The first step is to make a block diagram. This does not have to be very precise right away but is the starting point. The second step is to map out which servers and services are involved. The third step is to determine how the data flows and what the interactions are between the technical processes.
The toolbox; what do you need
When I go into a company to solve performance problems, I use Observer Expert or a GigaStor measurement solution. With these, I can easily find errors in the technical chain. I can see where the delay is, for example, or the errors in protocols. With those insights, actually solving grid problems becomes a lot easier.
Experience shows that, especially in the beginning, it is quite difficult to make a correct diagnosis from the many data. We can help you and have the tools to analyze your measurement data. Just give us a call!