Welcome!

If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

F5 Friday: Speed Matters

Google finally catches on and begins to develop what application delivery vendors have been doing for years.

f5friday

It’s a primary axiom of web operations and networking: speed matters. One has only to look at the number of niche products that focus on speed: WAN optimization, application acceleration, caching, content delivery networks, and continuing increases in the core speeds and feeds of our networks. So it shouldn’t be a surprise when “cloud” providers start talking about performance as a differentiator, which is exactly what Google recently noted at the Velocity conference.

quote-left The average web page takes 4.9 seconds to load and includes 320 KB of content, according to Urs Hölzle, Google’s Senior Vice President of Operation. In his keynote Wednesday morning at the O’Reilly Velocity 2010 conference in Santa Clara, Calif., Hölzle was preaching to the choir, addressing a crowd of 1,000 attendees focused on improving the performance and profitability of their web operations.

-- Google: How We’re Making the Web Faster

The aforementioned article goes on in varying degrees of detail, to describe how Google is making their web sites faster through a combination of protocol enhancements, GeoLocation, and compression. What’s ironic (and frustrating) is that these are many of the same solutions to the same problems that application delivery vendors have been espousing for years and that are leveraged by a variety of folks to improve the performance of their web operations. The irony of the organization that likes to develop everything from the ground up is that sometimes they hit upon something new and other times they essentially end up re-inventing wheels. In the case of Google’s improvements regarding web application performance, they’re in the middle. In general, all the improvements that Google espouses are ones that application delivery vendors have long known about and implemented.

Let’s briefly take a look at each one, shall we?


PROTOCOL ENHANCEMENTS

quote-leftOne of the foundational problems is that core Internet protocols such as TCP/IP. DNS and SSL/TLS haven’t been updated to reduce overhead that slows the loading of complex web pages. Google has developed refinements to address these challenges, which Hölzle said have been submitted to Internet standards bodies.

Hölzle said Google has seen a 12 percent improvement in the performance of its sites through refinements in its implementation of TCP/IP.

You’ll get no argument on this one from me except to disagree on the TCP/IP hasn’t been updated statement. There are a variety of TCP enhancements designed to improve its performance described in a variety of RFCs. These refinements to TCP/IP are commonly implemented by solutions like load balancers and application delivery controllers. F5 implements most of these in the core, optimized TCP/IP stack (called TCP Express – introduced back in 2005) that is the foundation for all F5 solutions deployed on its TMOS-based platforms. F5 specifically implements every modern TCP efficiency improvement, including:

  • Delayed and Selective Acknowledgements (RFC 2018)
  • Explicit Congestion Notification ECN (RFC 3168)
  • Limited and Fast Retransmits (RFC 3042 and RFC 2582)
  • Slow Start with Congestion Avoidance (RFC 2581)
  • Adaptive Initial Congestion Windows (RFC 3390)
  • TimeStamps and Windows Scaling (RFC 1323)
  • TCP Slow Start (RFC 3390)
  • Bandwidth Delay Control

Honestly, 12 percent is a pretty low improvement considering how much more can be achieved by a highly tuned TCP/IP stack pdf-icon :

  • Average of 35% performance boost for dial-up clients
  • Average of 79% performance boost for broadband users
  • Average of 56% reduction in TCP/IP errors (mostly TCP timeouts)
  • Increase bandwidth efficiency across existing ISP providers:
    -- 224% increase of data placed on the wire (3.2x improvement)
    -- 50% packet reduction on the wire (2x improvement)
    -- Eliminated 63% of “empty” TCP packets (2.7x improvement)

And as far as SSL goes, I can’t begin to stress enough that in many cases the performance of SSL is a combination of architectural choices and hardware limitations. Cryptographic operations are compute intense, and deploying them on web servers or application servers or virtual servers on which there are ceilings imposed on RAM and CPU is going to negatively impact the performance of those cryptographic functions. When the system has to simultaneously handle responding to web requests, managing sessions, and perform cryptography something is going to suffer and unfortunately the nature of cryptography means it’s usually the one that takes the hit and negatively impacts performance and capacity. Offloading SSL to external solutions designed to optimize the execution of cryptographic operations improves the capacity and performance of the application, the performance of the protocol, and the overall end-user experience.


LOCATION and COMPRESSION

quote-left He said Google also could serve pages faster if it had more information from DNS servers about an end user’s location. The nature of the DNS system means that Google sometimes can’t tell is a request is from Washington state or southern California.

Absolutely true. That’s why F5 partners with GeoLocation provider Quova and relies on its 99% confident replies regarding location of clients rather than the often inaccurate generalized DNS system.

quote-left Hölzle noted a glaring inefficiency in the handling of web page headers, which provide information about a user’s IP address, browser and other session data. The average web page makes 44 calls to different resources, with many of those requests including repetitive header data. Holzle said compressing the headers produces an 88 percent page load improvement for some leading sites.

While I don’t doubt this one is true at all, I’m not convinced this is always an appropriate method of improving performance for web applications because of the implications to the infrastructure. There’s a lot of information in the HTTP headers that is leveraged by infrastructure such as load balancers and caches and compression obscures that information, requiring decompression to inspect. Compression on small data sets – which HTTP headers certainly are compared to the size of other objects commonly compressed – is not universally a performance improver and in some situations can actually degrade performance. In fact, compression on data sets smaller than 1400 bytes (notice that’s smaller than the network MTU, and fits nicely inside ONE Ethernet packet) forcing compression can actually make performance worse because it takes longer to perform the compression than it does to deliver that one packet. Hölzle specifically notes that they are compressing headers for requests, which for the “average web page” are typically small – comprising little more than the HTTP headers and no payload.

Too, forcing infrastructure components between the client and the server to decompress and recompress HTTP headers as a time-saving mechanism may be appropriate in some situations but for complex enterprise data center architectures I remain unconvinced this would be appropriate in all situations. Stateless content seems to be key here, as there is no need for inspection of headers. This definitely seems like another one of those scenarios in which an intelligent compression technique should be used – applying compression only when it’s beneficial from a network, client, and infrastructure perspective.


YOU PROBABLY HAVE THESE CAPABILITIES TODAY

A large number of folks have solutions like BIG-IP Local Traffic Manager (LTM) and are using it as a simple Load balancer. That’s not a bad thing. After all, the core competency and foundational technology upon which BIG-IP is constructed is load balancing. But it does mean that they’re missing out on a huge variety of options that, like those noted above by Google, can dramatically improve the performance of their web applications.

You’ll note Google isn’t sharing these improvements with you so you can implement them, and the submissions to standardize some of the enhancements will take quite some time to ratify, if ever. I’ve no doubt that if you take advantage of their AppEngine or other related offerings that you’ll “get those enhancements for free”, so to speak. But that’s okay, because the improvements that Google is touting are, at least from outward appearance, nothing that hasn’t already been discovered and subsequently addressed by all the application delivery / load balancing vendors on the market, including F5. These solutions are part of what we call “application acceleration”  and “server offload” capabilities and they’ve been yielding as impressive (and in some cases more impressive) results for years for organizations large and small, public and private.

The best part is that you probably have a load balancer or application delivery controller in your data center right now, and it probably takes about three clicks of a mouse to enable many of these improvements on your applications today.


Related blogs & articles:

Follow me on Twitter    View Lori's profile on SlideShare  friendfeed icon_facebook

AddThis Feed Button Bookmark and Share

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.