I'd just finished reading the piece by Joanie Wexler "iCloud to test Wi-Fi Performance Mettle" when my iCloud invitation arrived. I was keen to see how much bandwidth it used for my first backup. Here's the result.

So there it is, just me with a lightly used iPhone, taking my link to capacity for the best part of an hour. What happens when dozens, hundreds, of iPhones hit your Internet link for the first time?

Addition: In response to some questions; the top graph is from a PacketShaper, the RTT graph is from PathView Cloud. For more information about controlling iCloud traffic with  PacketShaper see https://bto.bluecoat.com/packetguide/8.6/info/application-criteria.htm#ssl or ask me - I'm wonderfully cost-effective.

Cheers, Cliff.

Permalink | Leave a comment  »

Contentious? Semantics? I don't think so. If reactive means taking action after an event it's just optimistic nonsense to use proactive in the sense of taking action before an event. What about predictive? Sounds a bit like standing in your data centre waiting for your twig to twitch or something from the Kaiser Chiefs.  Maybe anticipate? Expecting and planing for (but not stopping) potential future events? How does that help?

Surely what we call proactive just means plain old reactive, but reacting in response to indicative signs giving high confidence that "By the pricking of my thumbs, something wicked this way comes".

If we want advance warning of something undesirable we have to accept the best we can achieve is to get low intensity signs that unambiguously foretell the coming storm. 

From a network infrastructure perspective, these warning signs are increases in latency, round trip time, packet loss and a whole heap of identifiable permanent or transient media issues. Chicken and egg often links these to reduced available bandwidth caused either by increased utilisation or reduced total bandwidth due to incorrect QOS configs, contended lines or any manner of plausibly deniable Telco statements.

For 'apparently' proactive management of network performance take a look at PathView from AppNeta. You'll get advance warning signs for every conceivable network condition and automatically triggered diagnostics to pinpoint what went wrong and how to avoid it in the future.

So if you're still convinced you can be truly proactive go for the lottery or the horses. If you're a pragmatic reactive go for pathview.

Cheers, Cliff.

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

Slow networks. Some people wonder if there's any other type, often because they simply can't confidently verify the problem is, or is not, the network. Here's a great solution that couldn't involve less risk or pain to try.

With 10 years of impeccable credentials in the US, AppNeta's PathView Cloud hit the UK just last year. It continuously monitors all the vital signs of your network infrastructure (see below) by invisibly exercising it and experiencing the same conditions as your applications. But, where applications and users just groan and get slower, PathView's reaction to declining conditions is to roll up it's sleeves and get stuck in with deep diagnostics to pinpoint where and what's happened.

It's described as having "instant value" and in my experience that's entirely accurate. A small download, a 2 minute installation and you're away monitoring and diagnosing to your hearts content. Many evaluations have accurately diagnosed long-standing network problems within minutes. If a download is not for you try a free evaluation using the microAppliance below.

Call me, Cliff Chapman, on 023 9265 8344 or 07887 506009 or email cliff.chapman@linkstatus.co.uk and see how PathView Cloud will help you or your customers solve network performance problems.

Permalink | Leave a comment  »

If faster websites improve online revenues you'd think that serious onliners would be continuously improving the performance of their web sites. And, there'd be no significant disparity between obvious competitors.

Take supermarkets. This grocery index from Keynote Systems shows web performance for Tesco and Asda. Quite a difference. Stats from Gomez show a similar story

This gap could be easily reduced, which should make Asda richer. What could be stopping them? Anyone can use Yslow to score a web site's performance and identify clearly described improvement actions.

Here's the Yslow score for Tesco (top) and Asda.

Yslow has scored the performance pretty much in line with the Keynote and Gomez results. But also, so much more than that. Drilling down on the individual components gives insight into how and why each affects performance - and how to fix them. I've just shown the top 8 here but you'll see many more if you run the test yourself.

Maybe Asda's site won't get faster than Tesco's, but if a free tool like Yslow shows you how to make your site faster, and faster sites make more money... Lightbulb?

Permalink | Leave a comment  »

There was plenty of Web Performance noise in July. Previously acquired by Compuware, Gomez acquired Dynatrace, Riverbed acquired Zeus & Aptimize and with performance announcements from Google and Yahoo the importance of Web App performance continues to accelerate. Keynote's latest Benchmark edition has a timely reminder about just how important Browsers are.

After realising that nearly all performance issues are caused at the 'front-end', i.e the Browser, Web performance whiz Steve Souders created a list of 14 rules which have been widely adopted as best practice. They can be boiled to down to to 3 categories

1) Reduce the data volume

2) Make fewer round trips

3) Do more in parallel

OK, obvious right? But amazing things can be done if you actually try it. Originally aimed at web developers, the tools to help you identify and improve performance issues are plentiful, mostly free, and easy to understand. Most are based on Browser plugins and all provide crystal clear information about performance bottlenecks and how to fix them. Some examples are Yslow WebPageTest Dynatrace Ajax Edition and HTTPWatch. If you need to test some 'what-if' scenarios try Fiddler.

1) Reduce the data volume: For years, Browsers and Web servers have been able to automatically zip some file types on the fly. This could save 80-90% network load but typically, it's not used. There are free tools to provide similar compression to other file types, for example minification of JavaScript (example). However, the best way to reduce data volume is not to send it at all which brings us neatly to...

2) Make fewer round trips: Each round trip can add tens or hundreds of milliseconds to the overall page load time. The best way to reduce round trips is to ensure expiry is used properly. This is often misunderstood to mean caching but there's an important difference. Mostly, caching works fine but when expiry is ignored Browsers must check back with the web server to ensure their cached version is still fresh, incurring an additional round trip for every element. When expiry is set correctly the page load time is dramatically improved. I've got a web page down from 5.2 seconds to 600 msec simply by addressing expiry.

3) Do more in parallel: The more you can get done in parallel the faster the page will load. I'll only mention the networking aspect but there are additional, more technical, Browser processing aspects. For networking, Browsers have a limit to the number of concurrent connections to the same domain. Typically, most Browsers now support around 6 to 8 (IE6 was 2!). What happens when you have 40 elements to load? The first few start and the Browser stalls waiting to hand out freed-up connections to the the next elements in the queue.

One easy way round this is to use a Content Delivery Network to handle your static elements. The more domains you use the more parallel connections your Browser can make. You can fool the Browser into making more connections by using alias domain names even though they have the same IP address. Test and compare your Browser's performance at Browserscope.org. Just changing Browsers may be enough to experience real improvements.

Try any of the tools mentioned above. You'll be struck by how simple they are to operate and the depth of information and quality of recommendations they make. Or you could look at products from Riverbed (aptimize) or Strangeloop which make the performance enhancements on the fly. Another newer alternative is to try services from the likes of Torbit and Yottaa where the changes are written on the fly in the Cloud.

Try them today and you will be well on your way to maximising Web App performance without spending a thing.

Cheers, Cliff.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Sometimes the only way to understand a network performance problem is to roll up sleeves and pore over a packet capture file. That is, of course if you're lucky enough to have one - taken at the right place and time. Our Cloudsmart service gives you options for getting your hands on packet capture files without leaving the comfort of your desk.

The strategic option is to deploy PathView's FlowView Plus module at network consolidation points such as the branch router's LAN port. The benefits are total secure PathView suite integration with packet capture icons shown in the same view as other events. You can read more about FlowView Plus here.

The second, more tactical option (or desperate, possibly), is to deploy a software agent capable of capturing the network traffic directly on the user's workstation. Our agent is a Steelhead Mobile Client, from Riverbed, with a specially customised configuration. Whenever - wherever there is a problem you can download and install the agent and be capturing packets within minutes.

Captures can be triggered by the user with just a few clicks (see instructions) or they can be triggered at our end. Either way they run for a user defined duration. When complete, the dump files are automatically transferred directly to us. We then send them back to you for analysis. Up till that point the service is totally free.You just need to register (see below) so we can create the agent assigned uniquely to you.

If you'd like us to analyse the dump files we charge a fixed fee for each problem. Yep, that's continued assistance until the problem is resolved, not just for that dump file.

Finally, bear in mind you may have other devices on the network that are capable of capturing packets. For example, the much loved (certainly by me) PacketShaper can do this, see the packetcapture command. If you want to analyse the packet capture files yourself you may find this page helpful.

Register free of charge for the remote packet capture service by joining our email newsletter below.

Sign up for our Email Newsletter

Permalink | Leave a comment  »

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

Permalink | Leave a comment  »

If you're struggling with measuring and diagnosing web performance with public web pages take a look at this.

There's a boundless set of free tools for measuring web site performance, but head and shoulders above the crowd there's webpagetest.

WebPagetest is a tool that was orginially developed by AOL for use internally and was open-sourced in 2008. The online version at www.webpagetest.org is an industry collaboration with various companies providing the infrastructure for testing your site from across the globe.

This is the recording of the recent O'Reilly webcast, Hands-on Performance Testing and Analysis with WebPagetest, presented by Patrick Meenan, the originator of Webpagetest..

If you're into web performance you will know the work of Steve Souders. See what he says about it.

Permalink | Leave a comment  »

via economist.com

"Everyone's gone to the Cloud" tra laa. Except they haven't. Everyone remains forever tethered to the ground by that slim fragile thread called their Internet connection. If this isn't operating at maximum effectiveness and efficiency how can anything else?

But how do you know?

For those that are content to believe their provider's stats and reassurances read no further.

Although the Cloud sounds like a single destination it's clearly (or cloudily) not so surely the best option would be to monitor and diagnose the performance of your link from the end you actually own and control.

That's exactly what PathView Cloud does for you. Get continuous monitoring of capacity, utilisation, latency, round trip time, packet loss, etc. Sounds good? There's more. Hop by hop diagnostics trigger whenever the link falls below the thresholds you've set for any of those parameters. This is pretty cool when you think that none of the Internet devices actually belongs to you. Get clear documented evidence that router IP this is dropping packets or router IP that has a capacity restriction or the link suddenly has massively extended round trip times - as just a few examples.

Find out more at http://bit.ly/aNmECq 

Once you know that your Internet link is whizzing along flawlessly take a look at the the latest developments for Bluecoat's PacketShaper. I used to be PacketShapers greatest fan but the first couple of years of Blue Coat product handling were dissappointing.

But wow, I was at a meeting with them yesterday where I saw the latest and greatest and what's to come. Massive Internet-oriented enhancements. I doubt that even Carlsberg could do it better.

What an exciting time - Yippee

Permalink | Leave a comment  »

Scratching your head trying to make progress?

ACT 1

Perhaps you'd like, at least initially, to get a feel for how well it might go without disrupting any users or drawing attention to yourself. Silently sneak in with covert action, easily deniable if the outcome is bad. Perhaps you're beyond that stage and faced with piles of unopened boxes of handsets ordered to get that great year-end deal.

Maybe you've worked out how make it all work - if only all those other apps weren't already hogging the network. What happens to their performance when you suck out the bandwidth voice needs. That's when someone lands the knockout punch and whispers "We have QoS from our provider - we do, don't we?" with the same reverence normally reserved for Penicillin or 3D contact lenses that let you see the world in err, 3D.

This of course, is meant to re-assure you - it doesn't. You know that QoS is being paid for, but no one knows if its actually doing anything. You also know that it isn't QoS, it's just CoS. The two have a sort of Gandalf/Gollum comparison. Has anyone ever tested it? Certainly not you. The comment just sets you up for a fall. You think of the Brian Setzer song "If you keep on sinnin', I'll stick another pin in. You're my hoodoo voodoo doll."  Darn why did they have to mention QoS, now everyone thinks it'll just - you know - work. 

Fade to Curtain...

ACT2

I'ts gonna be OK though, Gandalf-proportioned help is at hand.

Let's schedule that covert action. You drop a PathView microAppliance quietly into the network. no-one will know because its so small. If you squashed a tennis ball into a rectangular block, that's how big it would be. Installation is a breeze and it takes 1 minute to set up your path to that first branch office. Instantly, the Path is up and running and things look good. You realize you haven't been breathing for a few minutes like at school when you're waiting outside the Head's office.

"That wasn't so bad" you think, particularly as you're breathing again. No one's noticed because PathView has such a tiny footprint on the network - just a few packets a minute. OK now you want to go the whole hog. Using AppView Voice you run, first one call then 3, then 5 concurrent calls for just 5 minutes. Again its looking good. MOS score never worse than 4.2 with other vital signs like Latency, Jitter & Packet Loss all looking stable. Guess what shows you that?

You've been keeping an eye on the other applications and they seem OK too. Home straight now. First out of hours, that went well, then during rush hour morning, you run 10 concurrent calls for 1 hour. Tired of punching air, relieved and content, you amble back down Rocky's steps. "Why did I ever worry?" you think.

What you didn't tell anyone was that there was a sticky moment! Voice quality had hit a problem during the 10 concurrent call session out of hours. What was that faint recollection? Ah yes, Class of Service. Even Gollum came up with the goods. AppView enabled you to tag its Voice traffic with the ancient and mysterious EF symbol and you finally start using that providers service you's been paying for since 2009.

ACT 3

Voice deployment works fine with problems diagnosed and fixed in minutes as they occur by Gandalf himself - Well OK, by using the PathView Cloud suite. Actually that's better, because Gandalf has a habit of making himself scarce just when you need him.

Take well deserved bow...

Here's my 30 second Prezi on AppView Voice

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »