When you have a number of large remote offices that are downloading large documents or have limited bandwidth instead of looking at an asymmetric deployment you may want to consider a symmetric deployment.  A symmetric deployment positions the data closer to the user minimizing the effects of latency and reducing bandwidth.  The benefits of symmetric deployments include but are not limited to:

• Compression
• Data De-duplication
• TCP Optimizations
• Web Object Caching
• Non-Web Object Caching

For more information on symmetric acceleration see the Acceleration 102 White-paper.

I'm sorry to say that sometimes acceleration does not come about quickly, it frequently takes time to fine tune the system.  While you can quickly set up a virtual server and pool on an application delivery controller there are many items that can be tuned to enhance performance.  Settings within the virtual server like OneConnect and Nagle's Algorithm can be enabled via a quick selection, while other options take a little more time like WebAccelerator. 

To set up the base configuration of WebAccelerator with a library policy takes about 5 minutes.  Not too bad and this provides some quick performance improvements, however there are some advanced options such as  invalidations and configuring rules for dynamic caching  which enable you to accelerate more of the site but this takes time to set up.  The majority of the time is spent in the planning and testing phase.  Without proper planning and testing unexpected behaviours might be encountered - you may end up inadvertently diminishing the quality of the user experience.  Don't rush the process and the results will be worth it in the end. 

Performance may sound like a no-brainer when it comes to talking about acceleration however people look at different metrics when it comes to determining the performance improvements an acceleration solution will provide.  Last week I met with two different customers to determine the performance improvements that WebAccelerator would provide.  Customer 1 was mostly interested in end user response times, they have a number of branch offices around the world with latency ranging from 0 to 400ms.  The speed with which Sharepoint pages and documents would download at various speeds and latencies was the critical performance metric.  I am happy to report that the performance testing revealed roughly a 50% reduction in document download times.  Customer 2 was interested in measuring the hits per second the back could process to gauge the performance improvement.  In this instance the hits per second increased from about 200 to 2000. 

Will customer 1 see an increase in hits per second and will customer 2 see a reduction in page and document download times - probably however this isn't what is driving their need for an acceleration solution.  The metric used to determine performance gains is going to vary based on what is driving the need.  Are customers complaining about slow download times?  Have you recently acquired a new company resulting in more people accessing an already loaded application?  The choice of the performance metric is yours.  The trickier part comes in determining how much improvement is good enough. 

It helps to have a quantitative as opposed to a qualitative target.  When asked what the goal of testing should be one customer replied "I want my customers to be happy."  While it is noble to want happiness it unfortunately isn't a valid performance metric.   Once you have a quantitative metric make sure it is realistic and achievable, if the page is taking less than 1 second to download wanting a 50% reduction in response time may not be realistic. 

Having a site unavailable is probably worse than having a slow loading page.  Outages can occur for multiple reasons such as an overloaded back end server, an upgrade that didn't go as planned, or a power outage at the data centre.  Whatever the reason the end result is the same dissatisfied customers (some which may never come back) and lost revenue.  Nobody is immune to outages there have been some fairly high profile sites that have had outages over the last year including Amazon, Twitter, and Facebook - just do a search for outages and you'll find many more that have occurred over the years.

With the evolution of social media news of an outage spreads rapidly and reaches a far broader audience than previously as addressed by Stephen Pierzchala in his Newest Industry blog:

"I became aware of both of these outages through a combination of FriendFeed and Twitter within minutes of them starting. This information spread quickly. And, due to the nature of these new technologies, people were able to comment on the outages, and theorize about the cause of the problems these large online firms faced."

Gone are the days when you can fix the problem and get your site back on-line before anyone realizes there was a problem.

Luckily there are solutions available to mitigate the risk of outages.  A global traffic manager can direct users to a secondary data centre if a power outage occurs at the primary data centre.   An application delivery controller can be used to mark a node or server as down if it fails to respond and an F5 Networks iRule can be used to redirect users to an "Under Construction" or "Site Unavailable" page as highlighted in this DevCentral forum post.  But is presenting a "Site Unavailable" page really the best option or what happens if you have a single application server that goes down and no secondary data centre available to fail over to?  The solution: a little known feature in WebAccelerator called stand-in.

The stand-in feature allows WebAccelerator to continue serving cached content for a period of time after it has expired from cache.   Typically the first request after content has expired  will result in a conditional GET being issued to the server to revalidate the content if an error is received that would then be passed onto the customer.  With the stand-in feature enabled if an error message is received WebAccelerator will continue serving content for a configurable amount of time.  Isn't it better to serve some stale or expired content rather than no content at all?

Microsoft has been slowly rolling out a new version of it's Hotmail service. As of this week all users will be migrated from the 'Classic' and 'Full' versions to the new integrated version.  The 'Classic' version was a light-weight version designed for performance while the 'Full' version had many more bells and whistles and was designed for users with a faster Internet connection as the additional functionality resulted in heavier pages and therefore longer page load times. 

According to Dick Craddock, Group Program Manager for Hotmail, performance was a key concern with the new version:

We think improving download speed is some of the most important work we do.

Comparisons are provided of the response time improvement for four common tasks on the old and new version for both first time visits and repeat visits.  Kudos to the Hotmail team for adding new functionality and improving the page load times as often times performance is sacrificed in order to add new functionality.  

You would think performance improvements would be seen as a good thing however the original post introducing the changes has received over 2600 comments mostly from dissatisfied users.  The follow-on post has generated an additional 1100 comments.   Many of the complaints are regarding specific bugs or changes in the functionality, many people seem to be over-looking the performance improvements.  Anything new takes some getting used to like a new car - every time I get in a rental I have to take a few minutes to familiarize myself with where all the knobs and buttons are.

So what's more important improved performance and new functionality or maintaining the status quo?

What's more important the content on a site or the speed with which that content is delivered?  How long will users wait to read a blog post or a news article?  The team over at Pingdom have recently done a load size analysis of the top 100 Technorati blogs and the findings may surprise you.  Some of the highlights are:

• 35% of blogs had a front page greater than 1 MB
• 39% had a front page between 500 KB and 1 MB
• On average front pages had 63 images & 9 scripts

The authors provided some theoretical limits for estimated download times assuming a perfect scenario where bandwidth is 100% utilized.  In addition to bandwidth not being 100% utilized the page download time is going to vary significantly based on latency.  Let's take a look at the average number of embedded objects 63 images and 9 scripts on a connection with 200 ms of latency.  As has been previously discussed most current browsers by default allow 2 connections per host for content with the exception of scripts, scripts must be downloaded one at a time, so for a user with 200 ms of latency the additional minimum amount of time that must be added to the download time is 8.4 seconds which is broken down below:

1 HTML X 200 ms = 200 ms

9 Scripts X 200 ms = 1800 ms

63 Images / 2 concurrent downloads per host X 200 ms = 6400 ms

The low-end broadband theoretical limit goes from 8.4 seconds doubles to 16.8 seconds when latency is included in the equation.  This makes the case for acceleration solutions and site optimizations that much stronger. 

All this talk about front page load sizes and times got me to thinking what are the statistics for my blogs.

*Download times and latency captured from London, England.

A netscuse is blaming the Internet for being unable to complete a task.  In many instances an application delivery controller or acceleration solution can help eliminate these netscuses.

How many of these netscuses or something similar have you used or heard?

• I can't use the new self-service portal/application the pages take forever to load.
• When I went to submit my timesheet/take a course/pay a bill the site was down.
• The site is fine when using the corporate network but when I connect via my mobile it's just unusable.
• Our Internet connection has been flaky/erratic - must be too many people watching videos on YouTube.
• If I could install and use Chrome on my work PC I would be able to get much more done in a day - sites seem to load faster with Chrome. 

Got others, share them.

Thanks to my colleague Sam for helping me come up with an M word.  I was going to talk about multiplexing but Lori beat me to it.  So instead of multiplexing m is for Mozilla.  Probably one of the most popular Mozilla projects is the Firefox browser.  Firefox is the second most used browser according to recent statistics posted by NetApplications. 

I read an interesting post from the folks over at HttpWatch discussing the differences in the way IE and Firefox handle caching directives.  The difference in the way browsers handle cache directives means that more consideration needs to go into what settings to configure on the server to ensure that users accessing the site with all browsers get a similar experience.  Instead of messing around with the server configuration an easier approach would be an F5 iRule that would automatically insert the correct header based on the browser type.  I'm no iRule expert so I will leave the writing of that to somebody else.  Any takers?

Lots of "L" words kept popping into my head and I was having trouble choosing just one as they are all important.

L is for Latency - Lori and Joe have previously written about latency so I won't rehash what has already been said.

L is for Load Balancing - There are many types of load balancing that are important with acceleration;  server or local load balancing to ensure that the requests are evenly distributed across all available servers,  link load balancing to choose the best performing link for traffic and maintain high availability, and global load balancing to direct users to the closest data centre (particularly important when deploying symmetric web acceleration).

L is for Link Speed - Many times application performance is evaluated only from high broadband connections or on the LAN (hey another "L" word) which is not representative of the true user experience.  Application performance can vary significantly depending on the connection speed a page that takes 5 seconds on a high broadband connection may take anywhere from 30 - 70 seconds as this report shows.  While there may not be many people using dial-up connections these days the number of people using mobile devices to browse the Internet is steadily increasing.  The performance over mobile devices may show similar if not worse performance depending on the latency.

Knowledge is power in many situations like developing an acceleration strategy or choosing which candidate to vote for (sorry just couldn't resist making a reference to the U.S. presidential election - if you're a U.S. citizen please take some time to vote today).  When it comes to acceleration there are many things that need to be known when choosing an acceleration solution.

1. What are the primary applications that need to be accelerated?  Is the majority of traffic HTTP, FTP, CIFS or something else. 
2. Where are my users coming from? Are users concentrated to a few large branch offices are spread out around the world?
3. What percentage of my users are first time visitors vs repeat visitors?
4. How often does the content change?
5. What determines unique or customized content for users?  Is it a cookie, a query parameter or a database variable?
6. Is my content dynamic or deterministic?
7. How does the application perform on the LAN?  How does the application perform on the WAN?
8. When does content need to be invalidated?
9. How compressable is the content?
10. What percentage of your users are using mobile devices?

The answer to these questions will help you determine whether you need asymmetric or symmetric acceleration and what type of acceleration rules and policies need to be applied.