I wonder what questions were asked to get the responses published at  IT executives say they lack the tools to manage network performance. We're drowning in a sea of tools from freeware to Rolls Royce but apparently still not enough?

Or, do the respondents have plenty of tools which just don't deliver on their marketing promise. Or, they've bought the tools that should be able to deliver but not deployed them as they're too complicated, or output is difficult to interpret, or didn't budget for the training to get them working?

I think some of the reasons are nicely articulated in Is Your Network Monitoring Equipment Still Working for You?

Me? I'm real happy with my select little set of application performance management tools with pride of place going to PathView to keep the IT foundations running like a dream. If the infrastructure is shakey all else will wobble. 

Network and Application Performance Monitoring Demo

Slow Network? Application performance problems? Watch this short demo to see how PathView Cloud can quickly and affordably help you to pre-assess, continuously monitor and troubleshoot critical applications such as VoIP, Video, Virtualization and any...

Enter your email below if you'd like to get our newsletter for practical performance news tips and tricks.

You need to know the smallest capacity bandwidth in the direction of the server to the client and the shortest round trip time for the end to end path between them. Ping is good enough for RTT but measuring bandwidth could be tricky. Failing all else you'll have to trust your telco contract (the better answer comes later). These will help you estimate the best possible performance that network path will support. Be warned - Best Possible Performance will never be achieved in reality.

How to (very) roughly estimate BPP for free? Run the application on a LAN. Download a free copy of wireshark and follow instructions to get a packet capture that contains an example transaction of your new app.  Don't worry what else is captured, we'll filter that out next. From the 'Statistics' menu, select Conversation List > TCP. 

You'll get a pop up screen showing all the conversations that have been captured (so make sure your not also browsing any web sites you wouldn't want your mum to see). Highlight the one you want by identifying the app server address and make a note of the number of packets and bytes transferred in the server-to-client direction. 

Now you know these things. For the network path; bandwidth and minimum round trip time. For the application; how many bytes were transferred and how many packets it took to transfer them. Oh, and remember I said this would be a rough estimate.

Let's say bandwidth is 1M, minimum RTT is 100 milliseconds, the transferred volume is 500Kbytes and the number of packets is 400.

Ignoring overheads a 1M line can transfer 125Kbytes per second so 500Kbytes would take 4 seconds. But RTT is 100 msecs and it is encountered 400 times. This adds 40 seconds to the overall transaction time giving 44 seconds in all. Let's compare that with a LAN.

The transfer rate of a 100M LAN is 12.5Mbytes per second so the raw transfer is 100 x faster at 40 milliseconds. Let's assume LAN RTT is 100 microseconds. 400 round trips therefore adds 40 milliseconds extra delay. Total transaction time is 80 milliseconds.

Now picture yourself thinking "what if I try more bandwidth?". Here's why that doesn't work. Lets say you take your bandwidth 1M to 100M but cannot improve RTT. The raw data transfer reduces from 4 seconds to 40 milliseconds but we still have to add 400 round trips at 100 milliseconds - which is still 40 seconds. The 100M upgrade has just improved the performance from 44 seconds right down to 40.04 seconds!

Also remember that we've just estimated the BPP and that will never be achieved. There will always be other apps on the network consuming bandwidth leaving less for your new app. As bandwidth is consumed the RTT gets worse and you may have packet loss and other such nastiness on your network.

A better way to assess the likely performance of a new app is by

1) Using PathView Cloud to continuously monitor the network paths over which the application is to be run to get realistic values for available bandwidth (i.e the difference between total bandwidth and utilisation) and the RTT. This will also expose previously hidden network problems that will further erode performance.

2) Use those values to set up a WAN emulator, through which you operate the application on a LAN.

You will then directly experience application performance as if you were working from that branch. Testing in this way also allows you to evaluate possible fixes where the performance is unacceptable. Bandwidth and RTT parameters can be adjusted to discover what type of WAN technology is most suitable or WAN optimisation can be tested directly across the emulated WAN so you can see the degree to which performance can be improved. All in the comfort of your own office.

If you have a little bit of money and don't have all the time in the world we can do all this for you. Our Application Readiness service will deploy PathView to gather vital network stats, then bring WAN emulation to your site so that you can experience the branch's eye view of application performance. We can advise about different optimisation techniques that could improve performance and we can actually deploy optimisation in the emulated environment so before and after improvements can be experienced.

The Application Readiness testing is normally performed in a single day. We bring everything required to you. You just supply a workstation and an operator familiar with the application to be tested. Drop me a line if you're interested in understanding how your new app will work over the WAN before finding out the hard (and expensive) way.

Cheers, Cliff.

Our Cloudsmart service is the fastest and most affordable way to fix existing network problems and keep your network fit and healthy. It includes an initial baselining assessment of network health and performance, ongoing continuous performance monitoring, monthly performance reporting and proactive troubleshooting. See the press release.

Today’s leading applications are becoming increasingly performance sensitive. Performance-reliant applications such as VoIP / UC, IP Storage (back-up and disaster recovery), Collaboration, Application & Desktop Virtualization, and SaaS / Cloud services are highly dependent on specific performance parameters such as capacity, latency, jitter and loss.

Organizations often underestimate the task of network assurance prior to deploying a performance sensitive application such as VoIP, VDI, video conferencing to remote locations. Often, this is because the task seems too difficult to perform within constraints of time, resource and budget. The Cloudsmart service, based around the PathView Cloud suite lets you accurately measure how reliable your network will be. It is quick and easy to deploy and includes clear reports that show the condition of the network and actionable recommendations for improvement

PathView Cloud provides businesses with an inexpensive, easy to use means for continuously measuring performance parameters without impacting end user experience. When a problem is detected, PathView Cloud automatically tests each hop in the application delivery path to pinpoint the issue. A mature knowledge base provides detailed information about any highlighted issue, its potential affect on application performance and how to fix it.

Join our mailing list to get your free information pack showing how to keep your entire network tuned for performance. Joining the mailing list is also the first step to free registration for our remote packet capture service.

Sign up for our Email Newsletter

How would you like to visualize the performance of your entire network from one screen? That's LAN and WAN - Gigabit to skinny. I really mean performance not just availability or whether a device is responding. PathView Cloud can group, sort and present a live matrix of network path performance, colour coded to show compliance with user-defined thresholds of Capacity, Utilisation, Data Loss, Latency, Jitter and many more essential path characteristics.

Watch a little Prezi about it and use the 'More' > Full Screen option so you can zoom in on the screenshots.

I'll follow up soon with another Prezi for Path Diagnostics.

Go easy on me, I'm new to blogging! Hope you enjoy...

Cheers, Cliff.