We were surprised by the sinatra-jruby tests as well. If you read our "expected questions" section, it's not clear to us why Sinatra's performance on JRuby was weak. We'd love to hear from a JRuby expert about how to address Sinatra's "wrong" looking numbers.

Maybe the web-server choice (I didn't look to see what that was). But last I looked at it, the Sinatra router really is very naive/awful.

For the size of the framework, that may be the right choice ultimately.

On the other end of the spectrum is Rails, who've written their own Regexp engine for routing basically. It seems to be generally quite a bit faster.

All major Ruby frameworks have just awful routers though really.

Having had a look at the Gemfiles, it might be the choice of HTTP server used. I believe defaults to WEBrick, if no other server is present and I believe WEBrick is single-threaded.

I don't have any experience with JRuby, but this might be a possibility.

Yeah, the Sinatra numbers really ought to be more in line with the straight Rack numbers. Something's amiss.

Glad to see that on Rack, where I'd expect us to be fast...we are doing ok. On par with PHP (not a big thing to brag about, perhaps) and Play (worth bragging about, since it's Java/Scala end to end).

Obviously there's more work needed not just in JRuby but in the servers that server it and the frameworks that run on it. The slow performance of Rails here, for example, is largely Rails' fault.

But yeah...the sinatra numbers are wack.