Many website administrators, QA personnel, and development engineers are relying on load testing and performance testing of websites in an attempt to eliminate unwanted negative surprises in their server realms. These are especially high-traffic sites (mostly eCommerce or popular entertainment sites) which are employing load testing tools to ensure that their web servers can handle large amounts of user access. These tools enable the SA and DBA personnel to fine-tune the server environment with software and hardware enhancements to avoid performance slow-downs or complete server crashes.
The approach and method is a simple one: Within the functional/performance expectations of the website, create enough “virtual users” with the load tool to monitor the effects of the load within the load test time length (anywhere from 5 minutes to 1 hour is usually ample time), gather any metrics/error messages available and make decisions on what changes are necessary for optimal server perfomance in a high-load scenario.
There are many free and licensed load and performance testing tools available through the internet. Here is a partial list:
Rational Performance Tester
Depending on your level of technical expertise and knowledge of scripting, any of these tools may be sufficient for your load testing needs.
There are some general guidelines to be certain to consider when performing performance testing against any site:
1. It is a good idea to load test within a test environment only, especially to avoid crashing the production server with a large load.
2. The load script can cause many metrics collectors to be inaccurate when accessing the pages during the load test. Be certain that any third-party links (such as metrics counters, ads, etc.) are excluded from your load test script via a “blacklisting” method which will ignore those links.
3. Flash objects can also have an effect on how the website performs under heavy load as those objects are often grabbed from another server. These can be included/excluded from the test scripts at the discretion of the testing team (most likely using the “blacklisting” method mentioned in item #2) .
4. Server caching can be turned on or off depending on the decretion of the test team.
5. The test script itself can often be set to ramp up to a maximum amount of virtual users. For example: From 1 VU to 1000 VUs over a period of 30 minutes, then remain constant at 1000 VUs for another 30 minutes. This often helps the SA determine when the server starts to experience issues.
Common generic server error messages:
Server timeout (no response from server) most likely due to server’s inability to handle large user load can appear as the following errors:
EOFException(java.net.SocketException: Connection reset)
EOFException(java.net.SocketException: Broken pipe)
java.net.SocketException: Socket closed
In closing, whichever load test tool is selected for your tests, there is always some benefit to stressing the server with load whether it be small or large scale load. Avoidance of server crashes, slow performance and unpleasant user experience is the desired goal.