There are a lot different ways to improve the performance of your app. You're already doing one, optimizing. Especially if you start optimizing queries (ie fixing for n+1 queries). There are 3 other areas I would look into as well. Scaling vertically & scaling horizontally (http://en.wikipedia.org/wiki/Scalability#Scale_horizontally_vs._vertically), and the interpreter.
I like to scale horizontally first, at least a little bit. Having 2 app servers and a load balancer will increase the number of requests you can handle, and I like this approach initially because one app server is a single point of failure. Although in this situation the load balancer becomes a single point of failure. You could run 2 LBs for redundancy, but I that's a little outside the scope of your question.
After that, I would scale vertically. If you are running VMs like AWS EC2 instances, this is as simple as moving from say a m1.small to a c1.medium. Many other cloud providers have different ways to move up to larger servers. If you are running on your own hardware, benchmark your app and see where the bottleneck is (you should probably do this regardless, and do it first). If the bottleneck is memory, just upgrade the memory on your server and retest it. Then you may find the next bottleneck is the CPU, so you'll need to upgrade it.
The other area you should consider is the Ruby interpreter you are using. If you are using MRI (the default ruby interpreter), your leaving a lot of performance on the table. MRI is great for development, but in a traffic heavy site, I wouldn't use it if I could avoid it. MRI uses a Global Interpreter Lock (GIL) which basically makes your app single threaded. I could be wrong, but from my understanding, every process needs its own copy of the app in memory. So if you have 8 workers serving requests, your app will take up 8 times the memory.
There are several other Ruby interpreters out there like JRuby, and Rubinius. I don't know a lot about Rubinius, but from my understanding, it does away with the GIL and is a great alternative for MRI from a performance stand point.
I am a big fan of JRuby though. If you haven't already guessed, JRuby is a Ruby interpreter written in Java and Ruby. It's very stable and leverages the JVM, so you get native concurrency. And if you chose to go with Java 7, invokedynamic can inline method calls after the JVM warms up, and increase performance of JVM languages just like it would native Java code. With JRuby, instead of needing a new copy of the app in memory for every process, it uses threads which share a single copy of the app in memory.
If you do decide to go with JRuby, look into Torquebox which is an awesome application server built on top of JBoss. The lead developers for JRuby were recently hired by Red Hat, which already employed the developers for JBoss and Torquebox, so I imagine there is a lot of communication between these 3 groups.
Generic benchmarks are practically useless, but all the real benchmarks I've seen and heard about on real production apps comparing MRI to JRuby, the performance increase is absurd. I don't know if you'll get the same gains from Rubinius, but it may be easier to migrate to Rubinius than JRuby.
