Database Performance Optimization and Scaling in Rails
blog.appsignal.com
blog.appsignal.com
Typically, the performance issues are at the ActiveRecord level, when it's initialization 100s of instances of an object to render a table. With Rails, the #1 optimization technique is to use `ActiveRecord::Base.connection.exec_query ` to return a hash instead of initialization objects.
Side note: I still love Rails.
A little bit of knowledge about SQL and how a relational database works goes a long way.
Side note: I really dislike Rails.
no it doesn't. It only wraps updates in transactions, and a single line update would have an implicit transaction at the database anyway.
Think about what we both wrote here (sans the weak man argument, of course I'm talking about updates).
Rails does the right thing here in my opinion. Anything that happens between calling `.save` and it returning should be in the safe envelop of a transaction. It can't know that you're only going to emit a single UPDATE query in that transaction, plus the framework user expects any exception between calling save and it returning to roll back. There are outs if you need them. I've worked on a few reasonably high traffic and complex rails applications and I don't recall a time when the time between the last query and the commit caused an issue. Yes times when the transaction itself had got too large and that commit was taking awhile. That said, there were more of these types of locking issues in the project I worked on 10 years ago with MySQL and repeatable read isolation level than with PG since then which defaults to read committed.
Adding an index for a query can take it from seconds to me for the average response.
I follow the developments on YJIT and hotwire and absolutely love the communities there. The design is neat and that gives me confidence the stuff will be maintainable for decades to come.
Maybe I missed it but I’m surprised they didn’t mention Multi-Tenancy with Multi-Database since they have otherwise written about it*. For many apps this is not only a way to keep data isolated but is also a way to mitigate performance challenges that might come with a single large DB.
https://blog.appsignal.com/2020/12/02/building-a-multi-tenan...
I think there is a general misconception that if a language is not new and growing, then it is somehow going away. If anything, it's probably the opposite. Something like inertia is a much better predictor for language lifetime than than growth or features. In practice, the longer a language has been around and the more likely it is to stick around.
I think this is called the Lindy effect: https://en.wikipedia.org/wiki/Lindy_effect
> The Lindy effect is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.
As someone who doesn't write Ruby, even I can grok RoR in a few hours. And even though it's boring and not trendy, it gets the job done for a lot of use cases.