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.

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.

> 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.

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

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.

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.

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.

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.