4 ms·
I used to work on a product where the app server and database were in the same rack - so similar low latency. But the product was successful, so our N+1 would g
by inerte 1y ago
I used to work on a product where the app server and database were in the same rack - so similar low latency. But the product was successful, so our N+1 would generate thousands of queries and 1ms would become >500ms or more easily. Every other month we would look at New Relic and find some slow spot.
It was a Rails app, therefore easy to get into the N+1 but also somewhat easy to fix.
- 1-more 1y agoFor our rails app we actually added tests asserting no N+1s in our controller tests. Think a test setup with 1 post vs 10 posts (via factorybot) and you could do an assertion that the DB query count was not different between the two. A useful technique for any Railsheads reading this!
- simonw 1y agoThat's a good trick. In Django world I like pytest-django's django_assert_max_num_queries fixture: https://pytest-django.readthedocs.io/en/latest/helpers.html#django-assert-max-num-queries https://pytest-django.readthedocs.io/en/latest/helpers.html#... def test_homepage_queries(django_assert_max_num_queries, client): with django_assert_max_num_queries(10): assert client.get("/").status_code == 200 Or django_assert_num_queries to assert an exact number.
- jasonwatkinspdx 1y agoWay back in the prehistoric era of Rails I just wrote a like 5 line monkey punch to ActiveRecord that would kill mongrel if queries per request went above a limit. Probably some of the most valuable code I've ever written on a per LOC basis lol. But anyhow, merging that into a new project was always a fun day. But on the other side of the cleanup the app stops falling down due to memory leaks.