Everyday performance rules for Ruby on Rails developers
1–10 of 41 posts
Re: Everyday performance rules for Ruby on Rails developers
#2Some 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.
Re: Everyday performance rules for Ruby on Rails developers
#3> We can’t think of any good reason to do without [CDNn]
CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.
Re: Everyday performance rules for Ruby on Rails developers
#4Really 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 the overall purpose of improved performance and scalability.
Again, great, concise article. I’ll be recommending it to others and it will help a lot of developers!
Thanks!
Re: Everyday performance rules for Ruby on Rails developers
#5> We can’t think of any good reason to do without [CDNn] CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.
It's also an extra point of failure, an extra account to manage, etc. I have seen plenty of low-traffic Rails (and other) apps where neither hosting cost nor performance would be significantly improved by adding a CDN.
Re: Everyday performance rules for Ruby on Rails developers
#6> We can’t think of any good reason to do without [CDNn] CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.
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.
Re: Everyday performance rules for Ruby on Rails developers
#7Good 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.
Re: Everyday performance rules for Ruby on Rails developers
#8Some 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.
I like how the PostgreSQL docs use the term “profitable” for whether an index helps.
The purpose of the index often is to lower the “cost” (greater profit), by providing more values the query is accessing (filtering, ordering, selecting) within the index entries, for faster retrieval.
When users have the skills to generate query plans and review whether an index supports a query, verifying that the index is picked by the planner, and indeed lowers the cost, then they can answer this question for their own unique combination of hardware, data distribution, queries, and indexes.
As generic advice, I think more often than not the index won’t be used for Boolean columns. But it’s generic advice and it does depend.
As you suggested, users must check their own system.
My book also covers the 2 and 3 value variations (nulls allowed) for Boolean columns.
For readers wanting to build these skills themselves, here’s more info:
https://news.ycombinator.com/item?id=38407585
Good nudge that it depends!
Re: Everyday performance rules for Ruby on Rails developers
#9Good 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.
Re: Everyday performance rules for Ruby on Rails developers
#10> We can’t think of any good reason to do without [CDNn] CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.
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.