The network’s slow – why?
This has to be every network managers’ nightmare question. When end-users experience poor application response time they automatically assume that it is due to the network. In reality, it could be a problem with the servers or the applications being used. Wherever the problem lies, you need to identify it quickly.
The Best Tools for the Job
Tools typically used to resolve network issues such as the simple Ping and sophisticated Network Protocol Analyzers (sniffers) fall short. The problem is that the simple tools don’t give the full picture and the sophisticated tools collect too much data and require someone with specialist understanding to spend a lot of time (possibly hours) interpreting the data. Meantime, you are still under pressure to resolve the issue fast.
This is where iTrinegy AppQoS really can help. Simply connect AppQoS into any network segment and, with no configuration or agents, you will have concise, organized and easy-to-understand views of key network activity data within minutes!
Once plugged in, AppQoS non-intrusively monitors all the traffic passing it, including requests and responses to business applications. The analyzed data is viewed through an onboard web browser using integrated reports and graphs.
In a recent independent review iTrinegy’s AppQoS Application Performance Monitoring technology received comments like:
"...refreshingly simple to use..."
"Excellent approach to reporting"
"There are plenty of performance monitoring tools on the market, so anyone wanting to compete in this area has to stand out. PNC/QoS stands out because someone has sat down and thought about how to build a flexible product and make it usable"
Why Ping (and other ICMP based tools) does not give you the answers
A number of tools (including the standard ping and tracer commands) use ICMP packets to probe the network.
While tools such tools are good at finding out if a networked device is reachable and how long the ping took to come back, they do not tell you what you really need to know:
- Whether a network device is actually working
- Whether any particular application is working
- What the network response time is for any particular application
- What the total response time is for any particular application
- What competing network traffic may be causing slowness
Why is this?
Ping-based tools usually send out small fixed size packets to a specified target IP address. When this ICMP packet reaches the IP address the packet is modified and sent back as the response by the outer layers of the TCP/IP “stack” (sometimes the hardware itself).
This means that:
- Even if the device replies to an ICMP packet it may not really be “working” – it’s quite possible that only the network stack is working
- The device may not to reply to a ping (e.g. firewall blocked)
- The ping packet can easily be lost, particularly if the network is congested
- The timing of the ping packet bears no relationship to the response time of an application which must also have some server processing to deliver the result
Furthermore, these days networks are regularly configured for QoS (Quality of Service). This means that some important IP Addresses/Applications/Protocols will receive a priority service. In this case, any ICMP response times will generally be much higher (not QoS favoured) than the real protocol. Note, for example that in most VoIP installations, VoIP steams are given a priority service to ensure good call quality.
Why “sniffers” don’t help
A range of tools known as Network Protocol Analyzers or Network Packet Analyzers (most commonly described as “sniffers”) work by capturing all the passing packets and providing tools to analyze these.
While such tools are good for forensic analysis e.g. why something particular didn’t work or was slow, they don’t really tell you what you need to know:
- What the average response time is for an application?
- Whether a particular user received worse response time than the others?
- How an application compared against other applications?
- Whether the response time is worse than usual?
- What the trends in response time are?
- What is the competing traffic mix – are other applications/users to blame?
- Whether the problem lies in the network or the application/server?
Why is this?
In theory, a Network Protocol Analyzer could do these things, but they capture so much data that it is akin to trying to use microscopic images to do the job of a satellite image. As a result, the following issues can arise:
- There is just too much data
- It takes a long time to sift through – potentially hours
- You have to know what you’re looking for
- It is practically impossible to collect historically due to today’s data volumes (they fill their disks fast) – so no trend analysis is possible
- Despite modern Network Protocol Analyzers having advanced “filters” they usually need expert operation
With iTrinegy Application Response Time Monitoring technology packets are not captured and stored. Rather, the packets are inspected in real time and summary application response and usage meta data is stored on the data base. This allows easy investigation in just minutes of switching on/plugging in as well as the ability to hold data for significant time periods – a useful feature for ongoing monitoring.