The second I touch a network resource (typically the database) all the hand-crafted assembler in the world ain't gonna save me.
A stronger argument for a rails rip off in a statically typed language would be tool support, esp. consistent code completion.
Optimize your sql, then optimize your memcached.
That said, I've recently been working on a project building a webapp in Scala. The type safety Scala gives is amazing.
Want to write to master then read from a slave in the same http request [1]? Won't compile. Want to build a page without a tracking beacon? Won't compile. Want to prevent invalid input to enum fields (e.g., a string for which the only valid choices are "moderator", "subscriber" and "contributor")? Compiler has you covered.
[1] If you write to master then read from a slave, there is a nontrivial chance that the result of your write won't be mirrored to the slave.
On similarly sized server instances our Rails stack can handle about 10 requests per second, whereas our C++ / Java stack can handle about 400.
In practice the only time that I've seen the database be the bottleneck in Rails is when the database is accessed by people that pretend that ActiveRecord is in-process data and just use it like it's not querying a database (e.g. I've seen pageviews that require 30+ SQL queries). That or their database is set up in stupid ways and doesn't have indexes in the right places.
Rails is actually very slow. That said, I think a smarter approach than recreating the framework in faster languages would be to allow C or C++ into the main Rails project and to rewrite the hot parts in one of them. We sped up ActiveResource by about 35x by reimplementing it in C++ (with no changes required to our apps).
Is this representative? I built JMeter testing into a series of Django apps I built for the portal I worked for and the numbers were consistently higher. I always assumed they were similar in performance.
In any case, I haven't tried to optimize them (memcache and front-end caching were kept minimal and implementation as simple as possible) before going live (after, of course, making sure they were load-tested and would survive a reasonable load) so we could watch what breaks under load, compensate with extra iron, and correct it later. All those machines were heavily monitored.
What version of Rails is this? And can I talk you into open-sourcing it, if you haven't already? :)
When I do this sort of thing, I wrap ruby.h function calls with rb_protect, check the return code, and then throw a C++ exception to unwind the stack. There is an allocation cost to doing that.