But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more.
Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms.
Still love Ruby but the process model gave me a reason to hate N+1s.
There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html
The nice thing about first-class production sqlite support is that even if you do end up with n+1 queries, it's not as big a deal: https://www.sqlite.org/np1queryprob.html
Certainly I wouldn't care about it while prototyping. I can always go back and optimize queries with judicious `.joins()` or `.includes()` if it becomes a bottleneck.