Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everyday performance rules for Ruby on Rails developers

rorvswild.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Everyday performance rules for Ruby on Rails developers

#31

Post by zelon88 »

vemv wrote: post #10
c0balt wrote: post #6

Earlier quoted context omitted.

Or simpler, why do you need a CDN? It's rarely worth the additional work (setup + deployment) when most websites are not limited by bandwidth for assets.

If you're serving assets directly from S3 (or even from nginx) you're exposed to a "denial of wallet" attack, given the price markup on outbound networking.

So you have 10 scripts on your page, and you put them in 5 different hosts.

What does the waterfall on that look like? You're probably talking about a web app that transfers 2.6mb to the user who only wants to read 78 bytes of text. And your primary concern is the markup on outbound networking? Don't design crap pages and outbound networking isn't a problem. Most of the data transfer is fluff nobody wants or needs anyway.

You built the website! Now you don't think it's worth sending to the user? Or did you maybe go overboard when you were adding things to it?

Re: Everyday performance rules for Ruby on Rails developers

#32

Post by phendrenad2 »

ckdot2 wrote: post #19
resonious wrote: post #7

Good stuff but the `size`, `count`, `length` section just intensifies my dislike for ORMs. ORMs bury all of the SQL, just for devs to dig it back up when they realize it's important for performance. Now you have to be a SQL expert and an ActiveRecord expert.

Please, please don't mix up ORMs with ActiveRecords. ActiveRecords are one way to implement an ORM, but it's not the only way. I think many say they hate ORMs when they actually mean ActiveRecords. For bigger projects ActiveRecords suck, yes. But also you need to have some database layer logic which most likely does some Object & Relation Mapping (ORM).

I disagree. POROs are the way to go.

Re: Everyday performance rules for Ruby on Rails developers

#34

Post by allknowingfrog »

mrtesthah wrote: post #27
allknowingfrog wrote: post #26

Earlier quoted context omitted.

I don't want to live in a world where I can't pop into a Rails console and run something like `Foo.joins(:bars).any?`. More concretely, performance is on my list of "good problems to have". Businesses die in the time it takes to write raw SQL.

sometimes performance can be so bad that the business can’t launch in the first place.

Oh sure, it's all about knowing your requirements. I write raw SQL when performance or complexity call for it. My intention was to argue that both have merits, not that ORMs are the one true solution.

Re: Everyday performance rules for Ruby on Rails developers

#36

Post by andatki »

Yhippa wrote: post #29
qrush wrote: post #24

Really glad to see more basic Ruby / Rails content showing up on HN!!!

This got me to take a look at the Rails site and go through the Getting Started tutorial. It's really well-written and is probably amongst the best documentation I've seen out there. I would love to do more projects in Rails now.

That's great! Hopefully the authors of Rails Guides and the Getting Started tutorial see this. I'll share it with a core member and ask them to reshare it. I'm sure they'd appreciate seeing their hard work get recognized, and would welcome for your feedback.

Re: Everyday performance rules for Ruby on Rails developers

#38

Post by resonious »

vemv wrote: post #9
resonious wrote: post #7

Good stuff but the `size`, `count`, `length` section just intensifies my dislike for ORMs. ORMs bury all of the SQL, just for devs to dig it back up when they realize it's important for performance. Now you have to be a SQL expert and an ActiveRecord expert.

This particular is easy to pick up and remember. Also, a proficient developer looks at the SQL logs anyway as they develop a given feature. Rails' flavor of ORM is particularly composable and transparent - you can easily mix/match it with vanilla SQL.

I guess this is a fair point. It is easy to use SQL with AR. But when you do so, you get lambasted in code review by people saying "you can generate this same SQL with this arcane Arel incantation!!". But that is certainly a culture problem and not a technical one!

Re: Everyday performance rules for Ruby on Rails developers

#39

Post by hnatt »

durkie wrote: post #30
cattown wrote: post #28

The hint about using .pluck to only grab what you need from an ActiveRecord query is a pretty good one. I hand't realized you could do that. I assume this is telling us it doesn't actually make an ActiveRecord instance out of each row when you do that. And instantiating big bunches of ActiveRecord model instances just to grab a few fields from a result set with a lot of rows can be sooo slow.

That's correct. If i run `User.limit(5).pluck(:id)` the query it runs is `SELECT "users"."id" FROM "users" LIMIT $1 [["LIMIT", 5]]` and returns an array, not an ActiveRecord association

You can also do `User.limit(5).ids` which does the same thing.

Re: Everyday performance rules for Ruby on Rails developers

#40

Post by MrBusch »

Great list, but one caveat I'd add is this: While "SQL will always be faster than your code" is true, in the context of a sufficiently large app with many parallel requests the solution might still be to do some processing in the app because it can scale horizontally and (most) databases can only scale vertically and are thus more limited.
Post reply on HN