These kinds of tests are useless (to me at least) for three reasons.
First, these kinds of tests don't do anything useful and just show that some frameworks have more overhead than others. Once you have an app that was developed over years rather than hours and actually does a lot of stuff on every request, it's a whole different game.
Second, the kinds of applications I write rarely get more than 10-20 requests per second. If Rails would peak at 2500 rps as that YouTube video tests it at, that would be plenty. If I were writing some kind of IoT platform rather than a business app, I'd probably not start with Rails for that reason.
Third, for an actual web application, you want to consider what the user experiences, not just how fast the server responds. You can make an application feel much faster than the server response times by preloading on hover, (http) caching, async loading of things that are not visible yet, etc.
First, these kinds of tests don't do anything useful and just show that some frameworks have more overhead than others. Once you have an app that was developed over years rather than hours and actually does a lot of stuff on every request, it's a whole different game.
Second, the kinds of applications I write rarely get more than 10-20 requests per second. If Rails would peak at 2500 rps as that YouTube video tests it at, that would be plenty. If I were writing some kind of IoT platform rather than a business app, I'd probably not start with Rails for that reason.
Third, for an actual web application, you want to consider what the user experiences, not just how fast the server responds. You can make an application feel much faster than the server response times by preloading on hover, (http) caching, async loading of things that are not visible yet, etc.