4 ms·

I think you have missed where he said it had 20 people using it. Not 200,000. A single process wasn't able to handle 20. You'll be hard pressed intentionally

I think you have missed where he said it had 20 people using it. Not 200,000. A single process wasn't able to handle 20. You'll be hard pressed intentionally writing code that performs that slowly in a framework in another language. Ruby by default has an incredibly long list of "you can but you shouldn't" and things you need to be aware of, especially around concurrency. Other languages are mostly fast by default. When you follow some nodejs/express/whatever introduction tutorial and implement your first application in the most naive way possible, you'll end up with something that will easily scale to hundreds if not thousands of users out of the box. Do the same with ruby (or even with some python frameworks, to be fair), and stuff can break at less than a hundred users. And that's why yes, you can blame that on ruby. Or at least ruby how it is commonly taught.

ketamine__ 6y ago
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.
jacobsenscott 6y ago
There's nothing about the code being slow in the example. The example said the processes were io bound. The speed of ruby code is irrelevant. If it was io bound demo system had 2 processes sitting 99% idle. The example said there was 0.5 seconds of IO per request so each process could serve 2 requests per second. 2 processes would serve 4 requests per second. The mistake was running only one process per core. 10 processes would server 40 requests per second, and the cores would still be mostly idle. With rails you always run as many processes as memory allows, not one per core. Now that rails is thread safe you can have each process run a few threads. If you ran 10 processes and 4 threads per process you are up to 120 requests per second. If you really need massive concurrency that isn't anything special. But that is more than enough for 90% of the web apps out there.
the-dude 6y ago
This is nonsense, there is boatloads of frameworks and CMSes which can easily run into the 10s or 100s of milliseconds for the main request ( WP for example ). Serving only 20 users only has to do with how many workers were assigned. I actually implemented a high traffic RoR payment provider on minimal infra ( 1 small VPS ), and benchmarked a couple of Python CMSes and compared them to WP.
- michaelcampbell 6y ago
  > I actually implemented a high traffic RoR payment provider on minimal infra ( 1 small VPS ), and benchmarked a couple of Python CMSes and compared them to WP. I'd like to see your results if you still have them.

ketamine__ 6y ago

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.

jacobsenscott 6y ago

There's nothing about the code being slow in the example. The example said the processes were io bound. The speed of ruby code is irrelevant. If it was io bound demo system had 2 processes sitting 99% idle. The example said there was 0.5 seconds of IO per request so each process could serve 2 requests per second. 2 processes would serve 4 requests per second. The mistake was running only one process per core. 10 processes would server 40 requests per second, and the cores would still be mostly idle. With rails you always run as many processes as memory allows, not one per core. Now that rails is thread safe you can have each process run a few threads. If you ran 10 processes and 4 threads per process you are up to 120 requests per second. If you really need massive concurrency that isn't anything special. But that is more than enough for 90% of the web apps out there.

the-dude 6y ago

This is nonsense, there is boatloads of frameworks and CMSes which can easily run into the 10s or 100s of milliseconds for the main request ( WP for example ). Serving only 20 users only has to do with how many workers were assigned. I actually implemented a high traffic RoR payment provider on minimal infra ( 1 small VPS ), and benchmarked a couple of Python CMSes and compared them to WP.

michaelcampbell 6y ago
> I actually implemented a high traffic RoR payment provider on minimal infra ( 1 small VPS ), and benchmarked a couple of Python CMSes and compared them to WP. I'd like to see your results if you still have them.