Commit 4dc99f32 authored by James Edwards-Jones's avatar James Edwards-Jones

Adds docs for QueryRecorder tests

parent 1dc2e185
Pipeline #6992958 passed with stages
in 102 minutes and 23 seconds
......@@ -68,7 +68,7 @@ end
This will end up running one query for every object to update. This code can
easily overload a database given enough rows to update or many instances of this
code running in parallel. This particular problem is known as the
["N+1 query problem"](
["N+1 query problem"]( You can write a test with [QueryRecoder]( to detect this and prevent regressions.
In this particular case the workaround is fairly easy:
......@@ -117,6 +117,8 @@ Post.all.includes(:author).each do |post|
Also consider using [QueryRecoder tests]( to prevent a regression when eager loading.
## Memory Usage
**Summary:** merge requests **must not** increase memory usage unless absolutely
......@@ -39,6 +39,7 @@ GitLab provides built-in tools to aid the process of improving performance:
* [Sherlock](
* [GitLab Performance Monitoring](../administration/monitoring/performance/
* [Request Profiling](../administration/monitoring/performance/
* [QueryRecoder]( for preventing `N+1` regressions
GitLab employees can use's performance monitoring systems located at
<>, this requires you to log in using your
......@@ -25,3 +25,5 @@ starting GitLab. For example:
Bullet will log query problems to both the Rails log as well as the Chrome
As a follow up to finding `N+1` queries with Bullet, consider writing a [QueryRecoder test]( to prevent a regression.
# QueryRecorder
QueryRecorder is a tool for detecting the [N+1 queries problem]( from tests.
> Implemented in [spec/support/query_recorder.rb]( via [9c623e3e](
As a rule, merge requests [should not increase query counts]( If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed will silently reintroduce the problem.
## How it works
This style of test works by counting the number of SQL queries executed by ActiveRecord. First a control count is taken, then you add new records to the database and rerun the count. If the number of queries has significantly increased then an `N+1` queries problem exists.
it "avoids N+1 database queries" do
control_count = { visit_some_page }.count
create_list(:issue, 5)
expect { visit_some_page }.not_to exceed_query_limit(control_count)
As an example you might create 5 issues in between counts, which would cause the query count to increase by 5 if an N+1 problem exists.
> **Note:** In some cases the query count might change slightly between runs for unrelated reasons. In this case you might need to test `exceed_query_limit(control_count + acceptable_change)`, but this should be avoided if possible.
## See also
- [Bullet]( For finding `N+1` query problems
- [Performance guidelines](
- [Merge request performance guidelines](
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment