No site gets hit with millions of simultaneous, legitimate connections arriving within a second of each other. But don't write off the possibility of sudden spikes. To test for spikes, sharply increase the rate of new connections.
Calculating the sustained rate your site can support depends on your test definitions. Are you testing for maximum TCP connections or for the maximum number of users? A single user may have multiple TCP sessions going at once, may wander around a Web site with just one TCP session at a time or have short periods of time with no TCP sessions open at all. You will need to figure out what users normally do on your site. Do they read long pages of text, or rapidly jump through pages?
Your Web server tests should gather a combination of sustainable TCP connections, gets per second and response time. The number of gets per second determines how fast a single user session will execute. Response time tells how long the actual transaction will take. These elements can be tricky to test. Consider the differences in HTTP 1.0 versus HTTP 1.1 protocols. The newer HTTP version supports "keepalives," so you only need one connection, whereas version 1.0 requires one get for every element on a page. Older browsers use 1.0, so keep that in mind when determining the maximum number of users your site will support. The best bet here is to test a mix of 1.0 and 1.1 HTTP traffic, and make sure the benchmark tool pulls down all the objects and not just the main page. Otherwise you won't get a valid benchmark.
Testing applications, meanwhile, is different from the simple Web test. Grabbing the list of top stories off www.techweb.com, for example, is merely pulling a page with a few objects. But testing Web applications on a site entails measuring multiple steps, including filling out forms.
And don't forget that users come to your public Web site from the Internet, not from your LAN. That may sound obvious, but it puts your test in perspective: Did your end-to-end tests blast away at 100 Mbps with 2 milliseconds latency? If so, that's not a realistic measure. Most users have Internet links slower than 2 Mbps; the majority of users in the United States still rely on dial-up services. Latency varies, but for modem users, expect a minimum 200-ms round-trip delay per packet. If there are many transactions between the client and server, latency can easily add several seconds. This places an extra burden on send and receive queues (though you can optimize them to improve performance).
Most benchmarking tools can simulate low bandwidth. But if you want to inject latency or network problems like dropped packets somewhere beyond the end nodes, you'll need a specialty device such as the Shunra Software's Storm. Don't forget to stress-test your firewall, Internet router and any other device in between (see Step by Step).
Something Old, Something New
If you decide to upgrade your Web infrastructure or change the design altogether based on the results of your end-to-end benchmarking tests, beware of overbuilding your site. Say you have a Web server that usually gets about 1 million hits per month. One day your site gets a mention on nationwide television, and suddenly your traffic spikes to 1 million hits per hour for several hours. That doesn't justify restructuring your site to handle so much traffic: Buying more hardware and bandwidth than you really need is wasteful. You really can't plan for these extreme cases, so build only to your expected peak loads.
And before going live with your upgraded Web infrastructure, make sure you run the old and new Web sites simultaneously. It's best to launch the new site during your slowest periods, unannounced. This lets you iron out any lingering problems behind the scenes. Test the new site from somewhere else on the Internet, too, such as from a dial-up or DSL connection. Any upgrade, even one as minor as adding RAM, has the potential to break some piece of software, so test-drive your new Web site components thoroughly.
Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University Real-World Labs®. Write to him at mdemaria@nwc.com.
RSS
