One thing I've seen many times over the years is customer applications that used to perform quite zippy slow to a crawl under heavy load. The uninformed person might crank up performance monitor, see that RAM and CPU are high, and order a "bigger" server. What I have seen though in many cases is that the server resources may be high, but not because the hardware can't handle the load, but because the SQL operations aren't optimized.

One of the first places I suggest looking when researching SQL Server performance is to review the locking (which leads to blocking). Sure, faster hardware may help the queries to run faster so they release locks quicker, but throwing hardware at the problem isn't always the best solution.

SQL Server locks data even on read operations - and many people don't realize this. They are generally "shared" locks, but they are still locks. Addressing locking/blocking can often have drastic impact on the performance of the application.

Rather than explain all this myself in this post, below is a link to an article that helps understand lock contention and also mentions one of my favorite SQL Server "tricks" - NOLOCK.

http://www.sql-server-performance.com/articles/per/lock_contention_nolock_rowlock_p1.aspx

~Brad