Everyday performance rules for Ruby on Rails developers

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.<p>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:<p>High Performance PostgreSQL for Rails <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38407585">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38407585</a><p>The book helps readers build database skills with the overall purpose of improved performance and scalability.<p>Again, great, concise article. I’ll be recommending it to others and it will help a lot of developers!<p>Thanks!

&gt; We can’t think of any good reason to do without [CDNn]<p>CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.

&gt; Enable keep-alive connections. Keep-alive connections are reusable. They prevent having to re-establish a connection, as well as SSL negotiation. They reduce latency time for all pages made up of several resources.<p>Pretty sure this only applies to HTTP&#x2F;1 and you&#x27;ll get better performance with HTTP&#x2F;2:<p>&quot;Connection-specific header fields such as Connection and Keep-Alive are prohibited in HTTP&#x2F;2 and HTTP&#x2F;3&quot;<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Keep-Alive" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Ke...</a><p>&quot;HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests&#x2F;responses, as opposed to opening a new connection for every single request&#x2F;response pair. The newer HTTP&#x2F;2 protocol uses the same idea and takes it further to allow multiple concurrent requests&#x2F;responses to be multiplexed over a single connection.&quot;<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HTTP_persistent_connection" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HTTP_persistent_connection</a>

&gt; We can’t think of any good reason to do without them except for an application running solely on a private network.<p>Ever read those articles that explain half the internet is unavailable because of some random e.g. cloudflare outage? That.

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.

Really glad to see more basic Ruby &#x2F; Rails content showing up on HN!!!

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&#x27;s important for performance. Now you have to be a SQL expert <i>and</i> an ActiveRecord expert.

These performance rules applies for all backend development. Use compression and caching, index foreign keys in your database and tune your sql queries.

Great list, but one caveat I&#x27;d add is this: While &quot;SQL will always be faster than your code&quot; 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.

The hint about using .pluck to only grab what you need from an ActiveRecord query is a pretty good one. I hand&#x27;t realized you could do that.<p>I assume this is telling us it doesn&#x27;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.

Isn&#x27;t gzip disabled with https a thing since forever due to a security issue?

Nice list. Some good and some of them are contr-productive like promoting of use of preloading and calc in memory.

Excellent list, thank you for that. Implementing.<p><i>the CDN fauxpas is forgiven, nobody is perfect</i>

Step 1: stop using Ruby on Rails<p>I can&#x27;t even read the site with that text contrast. Why is illegibility a trend at all?