Reducing n + 1 queries using Bullet and RSpec gems

What is an efficient way to use Bullet Gem with RSpec? Right now I feel like if I use it with an existing unit test framework I get a lot of notifications or test failures due to n + 1 requests in the tests themselves that are unrelated to what is happening in my production application, for example when checking meaning or association. So n + 1 bug fixing does not require installing any items on my controllers or models, but rather requires installing something in my test setup to avoid throwing this particular error and I don't see any real performance improvement in my application.

+3


source to share


1 answer


The most efficient way is not at all. There could be some legitimate benefits to reduce n + 1 queries in tests, most obviously to speed up the overall execution time. It is possible, however, that you are either experiencing too much or making less significant gains than possible . I also generally find it unattractive to write additional code to help maintain the tests rather than contribute to the overall value of the application.

Let me suggest an alternative use of your time. Only unit test to the absolute minimum of your comfort level. I personally would like to focus on complex techniques related to validation-related questions as well as money or other math, you may have different priorities. Line drawing will free up a whole bunch of time by writing the most useless and fragile part of your test suite, which will take up the bulk of your maintenance budget.

Now, what do you do, all your extra time? Don't worry, we'll find something for you ... You can start by writing acceptance tests, especially for areas that use objects that you just dumped a whole bunch of unit tests on. Now, your n + 1 alerts actually come from the exact same place they will do when the user clicks on the page. Now you can delete all n + 1 queries.



But wait! Do not do this. Instead, spend a lot less time setting up your relationship to use the touch option . Then when the child is updated, the parent will be updated as well. What the hell does this have to do with n + 1 queries, you might be wondering. It looks like we're just adding queries ...

What is where Russian puppet caching is applied . Adding this and validating it correctly will consume freed unit testing and n + 1 exception times (and then some if you're not careful). The best part is that it is a more "real world", much more resilient to minor or irrelevant changes in your models and whatnot, and the huge performance gain for your application is vastly superior to what each n + 1 request eliminates, looks forward loading everything possible, foreseen the front. You need to move into nested caching as much as possible and load everything as lazily as humanly to take full advantage of this technique.

Long live n + 1!

+7


source







All Articles