25 ms·

There is a lot we don't know with the example given. It's unfair to blame Ruby.

• lostcolony 6y ago
  But it's not unique to this example. It's common; if you don't start out concerned about concurrency in Ruby, and just do the naive thing, you are going to fall over at -extremely- low numbers compared with most other modern languages.
  • debaserab2 6y ago
    The "naive" thing in Ruby, if you're serving HTTP requests, is to use some kind of app gateway that allows concurrency, such as puma or unicorn. It's just not all that viable to do something more basic than that unless you're willing to write all the request handling stuff by hand. That aside, a ruby script that can't handle 20 req/s on 2 vcpus seems rather suspect. I'd be really curious what that code looked like. I'm doubtful that it has much to do with the language and not the code design.
  • the-dude 6y ago
    If it is so common as you claim, could you point us to some public examples of this? I have never ever been concerned about concurrency in Ruby, or Python or PHP. Just deployed the number of workers which would be able to serve our peaks. I do write high concurrency application though, but those are not web apps and are not written in these languages.
  • jmcgough 6y ago
    I've used Ruby and rails for close to a decade and have never seen/experienced something like what they're describing, so I doubt this is really that common.