Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Web Infrastructure: Relieve Web Performance Anxiety: Page 2 of 5

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).