5 ms·

n+1 queries can be solved in many different ways – you can easily do`User.all.includes(:character_sheet)` for example, to perform just 2 queries: 1 for users, 1

by pugio 2y ago

n+1 queries can be solved in many different ways – you can easily do`User.all.includes(:character_sheet)` for example, to perform just 2 queries: 1 for users, 1 for their character sheet. 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 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.

ElatedOwl 2y ago
I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls. 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.
- chris12321 2y ago
  Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FRelation:load_async https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel. 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 https://rossta.net/blog/n-1-is-a-rails-feature.html
  - ElatedOwl 2y ago
    load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits
    - Lio 2y ago
      If that’s a problem for you right now I’d suggest giving JRuby a look as it has no GVL and true multithreading. Hopefully as Ractors mature that problem will be solved for MRI too.
deleted 2y ago
[deleted]

by pugio 2y ago

ElatedOwl 2y ago

I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls. 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.

chris12321 2y ago
Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FRelation:load_async https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel. 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 https://rossta.net/blog/n-1-is-a-rails-feature.html
- ElatedOwl 2y ago
  load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits
  - Lio 2y ago
    If that’s a problem for you right now I’d suggest giving JRuby a look as it has no GVL and true multithreading. Hopefully as Ractors mature that problem will be solved for MRI too.

deleted 2y ago

[deleted]