It's unfortunate that he included benchmark numbers because people will discuss the numbers rather than his main point. Since we're discussing the numbers anyway, antirez, were you running Sinatra in production mode? My benchmarks on my MBP look like this:
"hello", development mode 1620 req/s
erb :index, development mode 1000 req/s
"hello", production mode 1620 req/s
erb :index, production mode 1350 req/s
I assume Sinatra is doing some kind of template reloading in dev mode which may explain the speed difference?
That said, I think antirez is right that there are lots of opportunities for making ruby faster. I'm particularly hopeful about JRuby's use of invokedynamic and all of the work that is going into Rubinius.
The thing is, once you're able to scale out horizontally then you're back to riding the Moore's Law cost curve. If my ruby app requires 4 machines now, it'll require 2 machines in two years. Should I pay the up-front cost now of writing it in something lower-level? It depends, but in lots of cases probably not.
Hello Mnutt, I'm running the test into an MBA 11", it's very very slow, this is why this numbers are so different. The MBA is a good development machine as everything seems slow even if it is just a bit slow :)
Btw the PHP code is reloading the template at every request for sure. I pasted the example code I used on the blog.
Sorry, I just posted numbers to show the difference between dev mode and production mode.
I guess what I don't understand is: if you're running a site in development, isn't 250 req/s enough? And if you're running in production, do you need to reload the template on each request?
Ok my fault that did not said this in the blog post.
I was playing with Sinatra, and my real page involved substituting a few nested templates, with different parts of the site. News box, comments boxes, ...
The result was... 30 requests per second once a few templates started to stack, and with mostly toy code.
It is easy how things can get worse just doing a few mistakes along this path.
That said, I think antirez is right that there are lots of opportunities for making ruby faster. I'm particularly hopeful about JRuby's use of invokedynamic and all of the work that is going into Rubinius.
The thing is, once you're able to scale out horizontally then you're back to riding the Moore's Law cost curve. If my ruby app requires 4 machines now, it'll require 2 machines in two years. Should I pay the up-front cost now of writing it in something lower-level? It depends, but in lots of cases probably not.