When performance testing a web application (as in raw operations per second) I have seem many people try to benchmark their new system against the agreed performance level right off the bat. The problem with this approach is that most applications need to be tuned to get the most out of them. Optimistically firing off 100s of requests will most likely cause the server to choke and if you are unlucky die in a gibbering heap.
A more successful approach is to establish the maximum load that the application can cope with and then looking for performance bottlenecks. When operating at peak load any measurements are more likely to indicate true areas for improvement. Overloading the server is more likely to show hot areas around resource allocation where each thread is fighting for survival. By resolving issues around the first constraint (memory, threads, database connections, cpu) and then moving on to the next is most likely to yield rapid results.
On a fairly recent project the performance environment was not available until late in the project cycle. I was pretty sure that we would see some horrific results from the first performance run although I was confident that the architecture would support the anticipated load we had not run in a production like environment with production volumes of data. Sure enough the first few runs were far from satisfactory but over the following few days transaction times were down by just over two orders of magnitude. When an application first experiences heavy load it is important to maintain perspective and work through the problem. It is also helpful for this first run to be private to the development team so they can tackle the problem without attracting too much attention – ideally performance testing would be happening throughout the build. Most of the time ideally does not happen that often.