Navigation

Last Mile Monitoring: Web Performance at 40,000 Feet Altitude

 

My job requires frequent traveling between the East and West coast. On every trip, I can’t wait for the plane to reach the 10,000 feet altitude so I can turn on my computer and connect to the onboard Wi-Fi to get some work done. But as many of you might have experienced, Wi-Fi on a plane is not the same as the one at the local Starbucks.

On a recent trip to Boston, I decided to take along one of our monitoring agents to measure web performance and availability from the air. Talk about last mile measurements – what better place than in a plane 7.5 miles above sea level traveling at 500mph!

The Data

On February 15 and 17, I measured the performance and availability of various websites relying on the same agents we use to monitor performance from backbone and last mile locations on the ground. The data was collected relying on Internet Explorer 8. The time measurements below display the median value.

LAX to Boston – February 15 –  11 AM EDT to 15 PM EDT:

Web Performance – LAX – BOSTON 2/15/2012

Web Performance – LAX – BOSTON 2/15/2012

Boston to LAX  – February 17 – 7 AM EDT to 1 PM EDT:

On the returning flight I added a few more sites based on some limited observations of what passengers were accessing in the first flight: YouTube, Priceline, Expedia, and Netflix.

Web Performance - LAX - BOSTON 2/15/2012

Web Performance - LAX - BOSTON 2/15/2012

“In Flight” versus “At Home” Web Performance

To better understand what the “in flight” data means, we compared it to web performance data we collected from agents deployed at end user homes in Los Angeles. In this case three different ISPs and products: AT&T Uverse, Time Warner Cable, and Verizon Fios.

Web Performance - In Flight VS on the Ground Experience

Web Performance - In Flight VS on the Ground Experience

Obviously the end user experience “in flight” was not good, not for one or two sites – but for all of them. The performance was anywhere between 2 and 7 times slower than at home. The in flight data also showed a lot of failures, the great majority of which were due to the agent timing out after waiting 30 seconds for the page to load. (Most end users would have clicked reload after 10-15 seconds)

The Monitoring Future in the Sky

Based on this data and experience we are contemplating the launch of our own Predator Fleet to provide Web Performance Measurements from the sky (SkyPerf). I also met a Hollywood producer who was quite interested in this project. I pitched him a new horror movie called “Nodes on a Plane” – where a bunch of monitoring nodes are terrorizing various CIO, CTO, Network Engineers, Front End Optimization engineers, DevOps to provide optimal performance from the sky.

Who knows maybe even put a node on the moon as soon as we finish implementing the “Interplanetary Internet” protocol from NASA – to prepare for Moon colonization? Call me dreamer but once you are part of the Mile-High Club the Sky is NO LONGER the limit!

The Reality of Last Mile

But jokes aside, there is not much that the operators or devops of these sites can do about the performance issues their sites experienced on my flights. The performance degradation is not triggered by the application, or the ads on the page, or server CPU & Memory, and is unlikely caused by their ISPs or routers. Not sure application acceleration from a CDN or a performance optimization solution would have solved the problems. Maybe they would have minimized it, but the speed would still be slower than your Fios or cable connection at home.

At the end of the day the slowness is entirely related to “Last Mile” connectivity. It is directly correlated to the Internet Access on the plane, its bandwidth, the Wi-Fi router, the number of users accessing the router, the weather, and all the cat lovers watching the latest videos on YouTube.

The performance issues with last mile are not limited to the plane. They occur on your smartphone, mifi, and even at home or work. The root cause is the same, the quality of the network at that location is simply not good and impacting every site.

This is the number one reason why site operators want to monitor from the backbone – they want to eliminate performance issues that are out of their control. It is not because the numbers look better or want to hide problems under the carpet, rather because network noise is minimized providing a better and steadier picture. At the end of the day, no site operator wants to wake up at 3am because a user on a red-eye flight is having Wi-Fi issues.

Mehdi – The SkyPerf Captain

 

Written by

Posted on: February 28th, 2012

Category: Monitoring

Tags: