When searching for application performance metrics, what you’re looking for really depends on the application being monitored. A good question to ask yourself is: does the application I need to improve the performance of run locally on the computer without the use of the network? If it does require the network, does the application run largely locally in a console requiring only limited network access or does it require lots of network access like many web based applications? Loaded with this information, you have to move onto the next set of questions:

  • What details can you collect regarding the application performance issue? For example, is this a time of day occurrence? Does it only appear to be problem from a particular location? Is the issue localized to certain parts of the application?
  • How will you monitor the application performance? Where? Should the application be monitored at the server, the client or both? How many clients are there? If you need to collect details in a single location, a packet analyzer can do the job but, the level of detail will require someone experienced with the collection tool. To gain an enterprise level view of the problem, often times measurements from multiple locations must be collected. This is where packet analysis becomes cost prohibitive and flow collection must be employed.
  • What metrics will you need to collect to determine slowness? Do you need details on server, client or application round trip time? Must you collect re-transmitted packet counts, packet size or TCP window size? Find this out before you get started otherwise, you may not know what you are looking for.

Cisco AVC Support

When most consumers think about flow data, the details available in NetFlow v5 come to mind. The technology however, has come a long way from the 20 or so elements in NetFlow v5 to the tens of thousands available in NetFlow v9 and IPFIX. Flow technologies are now being used to export such details as: system messages, CPU utilization, round trip time, HTTP Host, URLs, packet loss, retransmits, jittter, VoIP codec, caller ID, layer 7 application, TCP window size and much more.

Cisco AVC Support

This is a technology that is starting to rival the details previously only available through packet capture. Today flow analysis can be used 90% of the time and packet analysis only 10% of the time. This is not to say that the flow industry will replace packet analysis because, it probably never will.

Flow Data’s Achilles Heel

As the elements of what flow technology can be used to export proliferates, it carries an Achilles heel: volume. The more details administrators try to stuff into a single flow tuple, the more overhead is produced. For example, requesting URL could cause what was a single flow to be broken up into multiple flows. To add salt to the wound more details means more bytes pushed into the same flow. A single NetFlow datagram used to send 30 flows could be used to send only 4 flows if excessive details are quested from each flow. Asking NetFlow v9 or IPFIX to export greater details starts encroaching on packet capture turf and begins to defeat one of the underlying intensions of flow technologies (i.e. less is sometimes more). For this reason, the trend in the industry that is supported by multiple hardware vendors is to allow the user to select what they want to export.

The third area that needs consideration when expanding the flow tuple to include more details is overhead. Asking the devices (e.g. routers) to match on more criteria and provide more information about each flow places greater overhead on the hardware. When the tuple is fixed, the processing can be done in ASICs however, if the vendor chooses to make the flow fields (i.e. elements) definable by the end user, it generally requires much more CPU.

Scalable NetFlow Solution

The final issue surrounding application performance metrics and Cisco AVC support is scalability. Enabling Cisco AVC flow exports can create A LOT of NetFlow or IPFIX traffic. Enterprise networks will require a scalable NetFlow solution. Check out the leader in NetFlow and IPFIX enterprise collection.

 

Mike Patterson author pic

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related