When you're dealing with the web, it's usually not the speed of an individual request that matters, because it's not a realistic indicator of how the server will perform under load.
What you really want to know is whether your server can serve pages up fast enough for users to have a good experience under expected load conditions.
To answer that question, you should get a tool like WCAT or JMeter and simulate load against your server, then look for where the bottleneck is occuring (if there is any).
For example, say by looking at your Google Analytics or stats account, you know that the most users you have in a day is 500. You then decide that you want to support a peak of around 750 users per day. If you break that down (depending on whether your site is used 24x7 or 9x5), you might discover that the maximum simultaneous page requests you need to support is around 10.
Then with WCAT or Jmeter you run a test that has 10 users simultaneously using the site and performing various operations. If the response time is acceptable (you could be the judge, but I would say less than 2 seconds for page load time), then you can stop there or continue to add users to see at what point the performance drops off.
Once you see the performance drop off, you then correlate that dropoff with what is going on with your server at that time. Are you getting a lot of hard page faults? Is CPU usage high? Is your DB overwhelmed?
Once you discover the bottleneck (if there is any), then you can look at ways to reduce the bottleneck. For example, if you are getting hard page faults and disk thrashing, maybe caching is the way to go.
But it's all about knowing what metrics you need to hit, testing against those, and uncovering and resolving bottlenecks.