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

21–30 of 41 posts

Re: Everyday performance rules for Ruby on Rails developers

#21

Post by andatki »

a12b wrote: post #11
andatki wrote: post #4

Really solid list! I went through all the Active Record, query design, and index design tips for PostgreSQL, and can +1 them all. Nice work. For readers who want all of these and more in book form, with a sample Rails app and big data to test with (generated), please consider my book: High Performance PostgreSQL for Rails https://news.ycombinator.com/item?id=38407585 The book helps readers build database skills with…

Thanks. I bought your book since the B1.0 version and I recommend it.

Thank you! Beta book period is nearly wrappped up!

Re: Everyday performance rules for Ruby on Rails developers

#22

Post by andatki »

silvestrov wrote: post #14
lukeasrodgers wrote: post #2

Some good advice here, but the “don’t index boolean columns” needs an “it depends” caveat, since Postgres will sometime use multiple boolean indexes to perform a bitmap index scan, which can be advantageous.

If the boolean values are not 50%/50% but skewed like 1%/99% then there can be a big advantage in using a partial index CREATE INDEX index_accounts_balance ON accounts (id) WHERE boolean_flag;

Correct, when the query conditions match the index conditions, and they both select a low proportion of the rows. For PostgreSQL and those unfamiliar with partial indexes, worth a read: https://www.postgresql.org/docs/current/indexes-partial.html

Re: Everyday performance rules for Ruby on Rails developers

#25

Post by __s »

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.

You're answering "Why do you need CDN?" with "Because I'm on AWS"

Their point stands: if you don't have a reason to use a CDN, don't use a CDN

Re: Everyday performance rules for Ruby on Rails developers

#26

Post by allknowingfrog »

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.

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.

Re: Everyday performance rules for Ruby on Rails developers

#27

Post by mrtesthah »

allknowingfrog wrote: post #26
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.

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.

Re: Everyday performance rules for Ruby on Rails developers

#28

Post by cattown »

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.

Re: Everyday performance rules for Ruby on Rails developers

#29

Post by Yhippa »

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.

Re: Everyday performance rules for Ruby on Rails developers

#30

Post by durkie »

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
Post reply on HN