The need for speed: Making Basecamp faster
37signals.com
37signals.com
My impulse would be to think that the hardware is responsible for most of it, which makes the article somewhat less interesting.
That said, the vast majority of the improvement was from the application changes, and not the hardware upgrades. Between server-side caching via memcached and conditional GET using if-modified-since headers and ETags, we were able to see dramatic improvements. We've also spent a lot of time analyzing the behavior of the Ruby garbage collector in our applications and making changes where appropriate to improve performance.
Did the database server upgrades make a difference? Of course they did, but it was an incremental improvement -- think along the lines of 10%. The point was to give us a longer scalability runway before we have to do things like sharding the database, not to provide an instant performance increase.
In general, in my opinion, profiling languages in web applications is a minor win because generally they're just glue. The real payoffs are on the client side (which you've just brought up) and the database side (which I wanted to make more prominent).