[pdimitar]

It is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database.

So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.

[jordanthoms]

Our data-heavy API returns JSON responses from our DB in ~40ms using ActiveRecord. So no, it doesn't waste 100ms on every request! We're serving around 6000 requests like that per second.

[pdimitar]

Well, you likely have a dedicated (or pretty strong) server.

The Heroku dynos I've tested with some years ago performed quite horribly. Only a proper Xeon server was able to achieve sub-100ms responses.

But hey, if Ruby improved in the meantime, cool.

[toomanybeersies]

Rails on Heroku is about the most inefficient combination you can get for a web server.

I've always thought of it as the platform you use for running toy apps with maybe a couple of dozen users at most and a low load. It's incredibly quick and easy to get a Rails app running on Heroku, a couple of hours at most. But you pay (in dollars and performance) for this.

[pdimitar]

You'd be surprised. I know companies paying $2000+ a month for Heroku and are still having performance problems with Rails.

(Then again, they have them with Phoenix as well but to a lesser extent.)

[jordanthoms]

Yeah, Heroku performance on shared dynos is really not great. The variability is very high also, so you'll get some requests seemingly randomly timing out. The dedicated performance dynos are better, but even more expensive. We were on Heroku for a long time but as the scale got too much we migrated to Google Kubernetes Engine which has been great.

[thirdusername]

That's not remotely true. If this is happening to you then you're almost certainly having N+1 problems which is architectural and would affect any solution you're using. Add google trace to get a breakdown of your requests SQL that's executing.

In an unusual situation it is possible in PG to have a very large pg catalog if you have thousands of tables and schemas which is resolved at run-time because Rails resolves models and types through db introspection, and the types specicially are only loaded during runtime. But that would be very unusual. I'm working on solving this in Rails because this unusual sittuation is affecting us.

[pdimitar]

I can only presume things have improved in the meantime.

Still, I regularly chat with Rails devs and to have a MacBook Pro 2018 return responses in 150+ ms is alarming. But you might be right that it could be a N+1 query problem.

Even without those though, I've still seen Rails apps perform quite horribly. So 50/50 from me, you might be correct but I wouldn't entirely discount the option that Rails is still quite suboptimal in terms of performance, compared to many other frameworks.

[thirdusername]

I mean I see rails perform horribly too, it's my job to go in and fix things, and I focus a lot on fundamentals (what's your DB doing, what data do you need to serve the request, what shouldn't be inside of the request-response cycle).

Because a lot of web developers these days build applications and ORM's are great but make certain patterns convenient so it's really easy to code yourself into places that don't scale. Then people reach for various caching solutions rather than taking a step back and looking at what's actually executing.

I've seen just about every bad pattern you can imagine and it's not usually obvious because the code looks simple enough. Like that permission check in your controller is actually serializing 1000 ids and querying against them, or that .first doesn't have an index so you're sorting the whole table, and much worse than that.

[pdimitar]

Sure. This is a thing regardless of language and framework. Point is, there exist some of them that are quite forgiving and don't give you a 150+ ms response time out of the box like Rails does for a number of projects I inherited in the past.

[jb3689]

ActiveRecord is configurable. You have options to bypass the serializer. Rails can't magically have the correct answer to every problem out of the box without tweaking

"The default behavior is slow!"

"Don't use the default behavior?"

[pdimitar]

But if you are going to override the defaults, then the argument of "Rails is performant out of the box" no longer holds water, does it?

[jb3689]

Was that an argument? It seems pretty clear that that is not the goal of Rails. I'm arguing here that "Rails can't be performant" is not necessarily true

[pdimitar]

Sadly often this is the argument, yes.

I am glad to see that there are much more reasonable Rails devs out there compared to some rather toxic individuals around in HN at least!

A lot of tech can be fine-tuned to be very performant. My point was (still is) that there exist technologies today that allow you to delay your scaling decisions much further in future, compared to what a stock Rails app (without any performance tuning) will.

[jb3689]

+1 I definitely agree with this. Today there are many strong languages/frameworks that are just as productive or close to as productive as Rails, particularly with more modern languages. I was really impressed by Phoenix when I worked with that. It was very easy to scale out when the time came because of all the support OTP gave you and because of design decisions like immutability by default