How Do I Know My Server Load?

The amount of traffic on a Web server at any given time is called the load. The percentage load is a measure of that Web server's utilization.

Load and Performance Testing

So, you are ready to launch your Web site. Before launching any Web application that you anticipate will generate moderate to large amounts of traffic, you should perform a structured server-load test. This is basically a calculated simulation of anticipated site traffic during a given period. The load test will assess the optimal performance of your Web site and help you define the maximum load it can handle. Ascertaining the maximum load a Web site or service will handle before crashing is called stress testing.

Using a performance-testing package, you can author scripts that generate a given number of hits during a given period (say, 30 minutes) or simulate a given number of users or sessions. The performance-testing package generates a load on the server by simulating the click stream of multiple users and then reports the server response times. By gradually increasing the number of users you're simulating and monitoring the server response times, you can project how much traffic will cause your Web server to go down. There are many third-party load-testing products available, ranging in price from free to thousands of dollars. Try a few before purchasing. Several packages I have used include the following:

• Mercury Interactive offers several options, including hosted load testing and software such as LoadRunner (www.mercury.com)

• Keynote provides hosted, Web-based testing services (www.keynote.com)

• RadView's WebLoad software is available at www.radview.com

• Empirix has a suite of products including e-Load Expert (www.empirix.com)

• Open STA also offers a free open-source testing tool (www.opensta.org)

• Microsoft offers a free tool called Web Application stress (www.microsoft.com)

• Searching the Web with Yahoo or Google found several sites discussing load testing, including Knowledge Storm, www.knowledgestorm.com, which listed many solutions and information on this subject. Typically, the more expensive solutions provide more functionality and can simulate more simultaneous users.

Here are some tips for preparing to load-test your Web site. First, compile site-usage statistics using your Web server's statistics logs. If your site is new, attempt to estimate usage of your Web site. Estimating these statistics can be difficult. At the very least, try to estimate the peak number of users and/or sessions per hour and the most popular route through your site.

These are some of the most important usage statistics for your Web site:

• Average number of users and/or sessions per hour

• Peak number of users and/or sessions per hour

• Most popular path through site based on analyzed traffic or real-use cases

• Most CPU-intensive Web pages or activities (such as logging in to the Web site, or performing database-intensive activity such as running queries and inputting large amounts of information)

• Most requested page(s) and top entry page(s)

• Average length of stay on site

• Most popular connection speeds used by visitors (56 Kbps, DSL or cable, T1, and so forth)

• Average response time or latency for pages

• CPU usage and other performance-monitoring statistics

After gathering your statistics or estimates, prepare test scripts and parameters. Test scripts simulate traffic patterns and usage throughout the site, and parameters set expectations for site performance.

A typical test script might include an area where users log in to the site and post information. The test script would simulate how users browse, log in, and post information on the site. For an e-commerce site, the test script might simulate users browsing for products, adding items to a shopping cart, and checking out.

NOTE

Users do not always browse your site the way you want them to, so you may need to develop your test scripts to reflect this. One way to do this is to write your test script so that a random number of user sessions are dropped at random time intervals.

The site's login sequence, shopping cart, and user checkout all query the database server. Including these sections of the site in the performance test is essential to ascertaining the Web server's response time when making requests to the database server.

In general you want to make sure you cover these parameters in your test scripts:

• Maximum number of users and/or sessions to simulate (if your Web site's peak number of users is, say, 500 per hour, you may want to test it for 1,000 users per hour to ensure that your site will not crash during peak usage)

• Length of sessions (each user stays on your site for an average of 5 minutes)

• Length of the test (a 1-hour test broken into three increments of 20 minutes each)

• Increments of the test (20 minutes each, 333 users each)

• Ramp-up times (adding users and/or sessions gradually and sporadically to simulate real Web traffic)

• Connection speed mix (majority of test users will access the site over a 56 Kbps connection; others will access over DSL or cable connections)

Now it is time to prepare your Web site for the load test. First, deploy a good copy of your Web site to your testing server, or to the production server if the site is not live. It is best to use a server similar to the production server, thus accurately reflecting your live Web site's performance. Second, turn on performance-monitoring tools. Third, perform the load test.

TIP

Never load-test your site on your production servers if the Web site is live. You don't want to crash your own Web site!

Assessing the results of the load test will provide valuable information pertaining to the Web site's performance and bottlenecks. Most load-testing software provides statistics on users and/or sessions attempted per hour, concurrent users and/or sessions per minute, page latency or response time per hour, and errors encountered. The concurrent users and session statistics will indicate your Web site's peak performance capability.

NOTE

Often called response time, latency is the delay experienced between the moment when a request is made to the server and the point at which the user can view the page.

If you run your performance test and notice that you have immediate problems with site response under very little simulated traffic, you have a bottleneck that requires examination. Typical bottlenecks for Web servers include CPU, memory, network, other servers (such as the database server), and code. Identifying and correcting bottlenecks before launching the site will help to avoid frustration and extra expense after launch.

Chapter 2 includes more detail on how to monitor and understand the performance of your Web servers, identify bottlenecks, and tune servers to run efficiently. Inability to handle the load is one of the most common causes for site failure, so knowing what to expect beforehand will put you ahead of the game.

NOTE

When configuring your Web and database servers, pay specific attention to any extra, nonessential software you load on each server. Even software as simple as an enterprise-monitoring agent or an antivirus program can have an impact on your server's performance.