In order for the benchmark results to be useful, it is critical that the server under test is the only bottleneck in the system. It is all to easy to allow the network or the client machines to become the bottleneck, giving entirely inaccurate results. Preventing this can be difficult, and usually requires significant expenditure on hardware. For example, conducting an accurate SPECweb test against a modest 750 MHz Pentium III server will require more than 100 Mb of bandwidth to the server (ie. several network cards) and at least four client machines.
When testing even the most modest of servers, at least 100 Mb will be required between the clients and server. A 400 MHz Celeron is easily able to saturate a 10Mb network when serving static content, and will saturate a 100 Mb network when serving large files. For SPECweb benchmarking, several network cards or gigabit ethernet to the server will be required.
When conducting the tests, monitor network I/O to see if it comes close to the network limits; tools such as httperf report this for you. (Remember that on an Ethernet network, maximum throughput in practice is typically no more than 80-90% of the rated maximum (ie. a 100Mb network will typically support a maximum throughput of no more than 90Mb).)
It is critical that the client machines themselves should not become the bottleneck. The likelihood of this occuring varies with the benchmarking software in use. To eliminate this as a possibility, several clients are used. To determine whether or not the clients are the bottleneck, run the same benchmark twice with different numbers of clients (such that the requested load on the server is the same in each case). If the results differ, then the test was client-bottlenecked, and the number of clients should be increased. Never use system load or percentage CPU usage on the clients to determine whether or not they are bottlenecked; several benchmarking tools (such as httperf) report 100% CPU usage even when they have spare capacity.