It’s rare for any major application or website to go live without going through performance testing. It’s an extremely important activity that requires effective planning and execution. Based on our experience in implementing web applications including websites for global clients, we believe a well-planned approach to testing new web applications goes a long way in ensuring enhanced user experience. Below are 10 tips for planning and preparing for performance testing of a new website or a web application.
- Focus on performance – Performance should be integrated into the design from the very start of the new web application project rather than an afterthought. Performance testing should not be considered a one-time activity.
- Identify key pages to test – It’s not always possible to test every page, so it’s important to select the pages that are expected to have the highest hit rates. The IT or marketing departments usually have the web analytics stats for the site and will be able to provide information on the sections of the site that receive the most traffic.
- Know your target performance metrics – Well before embarking on any performance testing, you will need to identify realistic performance metrics. These may include page load times, number of concurrent users, etc. Typically you should aim to get these performance metrics before the solution is designed. This will ensure the architecture is able to cope with the expected loads and performance targets.
- Measure base line performance – Plan to measure baseline performance figures for the old site (using the old CMS if it’s a migration) and the new CMS without any customisations. The reason for this is that you will typically want to prove that the ‘new’ site offers the same performance levels as the old one. While migrating to a new CMS platform, it’s important to establish performance levels of the new CMS, without any of your customisations, so as to ensure that the customisations have not degraded performance of the site.
- Recreate the production environment – Plan to execute the tests on either the production hardware or a replica of production. If performance testing can’t be executed on production or hardware that replicates production, then the performance figures will need to be adjusted or extrapolated for production. It’s important to at least recreate any clustering and other configuration from the production environment to make the testing as realistic as possible. It’s important to ensure that the hardware used for testing doesn’t have any other applications running when the testing is due to be executed; this will ensure ‘clean’ performance figures.
- Avoid network congestion through off-peak testing – Ensure testing is planned for a period when there is a minimal load on the network such as during the weekend or sometime in the night. This is to avoid loading the network with testing traffic when the rest of the business is using the network for normal ‘business as usual’ activities.
- Team Management – Plan on having the right people available during the tests – e.g. DBA, Server Administrator, Technical Architect and, if possible, infrastructure architect to monitor network hardware such as load balancers.
- Application Configuration – Configure the application and servers for production – i.e. switch on caching, set an appropriate logging level, etc. Don’t forget to disable DEBUG level logging unless you want the additional detail, as excessive logging may slow performance of the application. Normal production level logging is usually set to INFO, so it’s logical to use the same for the performance test.
- Test the final production release – Ensure you’re running the production release software during the testing. It may be tempting to execute testing against an early release of the software, but unless this is the first of many performance tests, it is essential that the final production release is used. There is always a risk that the performance profile of the software will change from release to release.
- Use monitoring utilities – Switch on application and monitoring utilities to record key information such as CPU and memory load, database query times, etc. It’s important to understand what’s going on at the web server, application server, database and other key integration servers. For database centric applications and sites (and most are) effective database monitoring is essential. For example, an application executing around 100 queries for every web request, can place a huge strain on the servers and reduce the number of concurrent requests that the application can handle. It’s an extreme example, and one that I have encountered in the past, but certainly proves that it is important to keep an eye on the number of queries being executed for a given web request.
Performance testing of web applications offers some interesting insights on why an application can fail. I am sure you may have a different experience or issues to talk about, which we would be very interested to hear about. Please leave your comments or other tips you may want to share in the below comments box.