Performance is a critical business issue. Research has shown that 75% of users will go to a competitor if your web performance is poor. Sites often bog down or fail during peak traffic times, exactly when they need to perform at their best.
There are only a few reasons why websites go down under heavy load. If you know what these top performance landmines are, you can avoid them by testing your website the right way, before you go live. Testing your site under realistic load is the only way to uncover and eliminate the performance landmines before they cost you sales and customers. Below are the top two performance landmines to be aware of as well as details on how best to avoid them.
The average web page is now more than 1 megabyte. This isn’t a case where bigger is better, it’s bad for site owners and for users. If pages continue to grow at this rate, the average page will hit 2 MB by 2015. The main culprits for this growth are images (which account for more than half of the average page size) and third-party scripts like analytics, ads, and social sharing buttons.
To prevent this from surprising you, all it takes is to test your application from the perspective of your real end user. This allows you to prevent “super-sized” web pages from hitting the public web. Things that impact page load time:
Missing Files: When deploying an application into production it is important to not forget to deploy all content of that application. That includes all static resources such as CSS, JS or Image files.
Problems like this can’t always be found in a traditional load testing environment for two reasons:
It is therefore recommended to test from the In- and Out-side. Files might be deployed on AppServer but blocked on Web Server or Load Balancer and certain files might come from a CDN, testing the CDN settings is important.
Unfortunately these restrictions are often not well communicated. Therefore an application that worked well in the test or staging environment will either break or experience an additional performance impact for most end users because of these existing restrictions. The recommended steps therefore are:
Slow Web Server Modules: It is important to only use modules that are really needed. It often happens that modules and extensions are installed and activated for every application that is served by that web server. Where one module might be required by Application A it might not be needed by Application B. Therefore make sure to only activate those modules for a specific application that are really required.
When adding a new module/extension make sure it’s designed to handle the load that you expect. Common problem that we’ve seen is that extensions are downloaded from the web which was created for small demo projects where they worked well but which have never been tested in large scale production environments. Identify problems like this by watching high times between Web Server Tier and Application Server.
Make sure to test on your production environment with proper load. Additionally, check the following things:
In part two, I’ll provide details about the third top performance landmine – Overhead through Logging/Tracing.
About the Author:
Andreas Grabner Technology Strategist, Compuware dynaTraceAndreas is a performance enthusiast who has been working in this field for the last 15 years. He helps organizations find the real problems in their applications and uses this knowledge to teach others how to avoid these problems by sharing up their engineering best practices. Andi blogs on blog.dynatrace.com Read More
Come see Andreas Grabner at the Software Test Professionals Conference in San Diego, CA – March 29-April 2. Andreas will lead sessions Top Performance Problems and How You Can Test for Them & Application Performance Clinic
on Sunday March 29th.