4 ms·

Any thoughts on doing the same thing with Sinatra and/or Padrino? Also do you think rails 4 will make any improvements? ~20 reqs per second with barely any con

Any thoughts on doing the same thing with Sinatra and/or Padrino? Also do you think rails 4 will make any improvements? ~20 reqs per second with barely any concurrency seems so low. Is heroku, ruby or rails the culprit for such low throughput?

jrochkind1 13y ago
> Any thoughts on doing the same thing with Sinatra and/or Padrino? Also do you think rails 4 will make any improvements? I am not familiar enough with either of those frameworks to know if they can do multi-threaded concurrent request dispatch -- if they can, then it'll apply to them too, I think. But I'm not interested in doing the experiment myself. I don't think rails4 fundamentally changes the picture, as far as _comparing_ different app servers. > ~20 reqs per second with barely any concurrency seems so low. Is heroku, ruby or rails the culprit for such low throughput? It may be mostly that I was choosing to model relatively slow apps. With an app that takes 100ms of _cpu time_ to return a response, and 4 cores -- the -theoretical- maximum is only 40 reqs/second, it's not possible for it to get any higher than that. For my own work, my apps don't get a whole lot faster than what I modelled, but others might. But I wasn't really setting things up to look at the actual requests/second numbers -- in what I set up, the relationship between the scenarios is more significant. If you wanted meaningful absolute numbers (or to compare ruby/rails to something else) you'd probably want to test a real app doing real things, not my simulation app. I also think, generally, "requests per second" is not the right number to be looking at -- what you (and the users or clients) really care about is how long the clients spend waiting for a response (at median, and how much variation), right?
- rartichoke 13y ago
  Yeah latency is more important but wouldn't you cache most results in a real app. I think 37 signal's showed us that a rail's app is capable of delivering low latency responses. In some presentation David mentioned most responses are sent out in 20-50ms but he didn't mention the hardware involved.

jrochkind1 13y ago

> Any thoughts on doing the same thing with Sinatra and/or Padrino? Also do you think rails 4 will make any improvements? I am not familiar enough with either of those frameworks to know if they can do multi-threaded concurrent request dispatch -- if they can, then it'll apply to them too, I think. But I'm not interested in doing the experiment myself. I don't think rails4 fundamentally changes the picture, as far as _comparing_ different app servers. > ~20 reqs per second with barely any concurrency seems so low. Is heroku, ruby or rails the culprit for such low throughput? It may be mostly that I was choosing to model relatively slow apps. With an app that takes 100ms of _cpu time_ to return a response, and 4 cores -- the -theoretical- maximum is only 40 reqs/second, it's not possible for it to get any higher than that. For my own work, my apps don't get a whole lot faster than what I modelled, but others might. But I wasn't really setting things up to look at the actual requests/second numbers -- in what I set up, the relationship between the scenarios is more significant. If you wanted meaningful absolute numbers (or to compare ruby/rails to something else) you'd probably want to test a real app doing real things, not my simulation app. I also think, generally, "requests per second" is not the right number to be looking at -- what you (and the users or clients) really care about is how long the clients spend waiting for a response (at median, and how much variation), right?

rartichoke 13y ago
Yeah latency is more important but wouldn't you cache most results in a real app. I think 37 signal's showed us that a rail's app is capable of delivering low latency responses. In some presentation David mentioned most responses are sent out in 20-50ms but he didn't mention the hardware involved.