A useful test for measuring end-to-end performance is called functionality verification. It confirms whether the Web page that was downloaded is the real thing or an error page, so you can detect when your Web server can't reach the database server. Knowing your server can handle 1 million connections is fine, but if 40 percent of those connections contain SQL error messages, you have a problem.
Use as much realistic traffic as possible in your Web site testing. Download a typical page or execute multiple database inserts and queries. Merely initiating a TCP "open" and "close" isn't enough, unless you're conducting a Layer 4 firewall test, for instance, where content doesn't matter much. But if you're testing a Layer 7-aware device, you need real data.
Simulate user behavior, too, to ensure the test is realistic. Walk through the site, performing multiple tasks and factor in some "think time." It takes longer than one second for a user to download a complex Web form, fill it out and submit it, so add a few seconds or a minute before submitting a form to ensure it's an accurate representation.
Choosing the right benchmarking tools for your tests can be challenging. They vary in functionality (see the table, below, for some examples) and price. In some cases, you'll need to buy both benchmarking hardware and software. You can also try shareware, freeware and cheapware benchmarking tools, but they may lack necessary features. A realistic test also includes multiple types of traffic and staggered start times for your user's scripts. Which protocols you test depends on what services your site offers. For a Web test, you may only need HTTP and HTTPS. But if you have a Layer 7 firewall and your network most often uses HTTP, FTP, DNS and SMTP, you'll need to test the firewall with all these types of traffic.
And it's best to test for sustainable traffic, because traffic ramps up over a period of time. This way the device being tested won't be overwhelmed, and you'll find the maximum capacity of the device before it fails. So start with 100 connections, then 500, then 1,000 and so forth. Traffic will arrive at the site in shifts--some will be handshakes, others data transfers and sessions terminating.