2020-10-30 14:08:56 -04:00
---
stage: none
group: unassigned
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-30 14:08:56 -04:00
---
2018-01-15 10:21:04 -05:00
# Query Count Limits
2018-02-13 10:40:23 -05:00
Each controller or API endpoint is allowed to execute up to 100 SQL queries and
2020-12-11 13:09:57 -05:00
in test environments we raise an error when this threshold is exceeded.
2018-01-15 10:21:04 -05:00
## Solving Failing Tests
When a test fails because it executes more than 100 SQL queries there are two
solutions to this problem:
2018-11-12 19:39:21 -05:00
- Reduce the number of SQL queries that are executed.
2021-03-16 14:11:53 -04:00
- Disable query limiting for the controller or API endpoint.
2018-01-15 10:21:04 -05:00
2021-03-16 14:11:53 -04:00
You should only resort to disabling query limits when an existing controller or endpoint
2018-01-15 10:21:04 -05:00
is to blame as in this case reducing the number of SQL queries can take a lot of
effort. Newly added controllers and endpoints are not allowed to execute more
2020-12-11 13:09:57 -05:00
than 100 SQL queries and no exceptions are made for this rule. _If_ a large
2018-01-15 10:21:04 -05:00
number of SQL queries is necessary to perform certain work it's best to have
this work performed by Sidekiq instead of doing this directly in a web request.
2021-03-16 14:11:53 -04:00
## Disable query limiting
2018-01-15 10:21:04 -05:00
2021-03-16 14:11:53 -04:00
In the event that you _have_ to disable query limits for a controller, you must first
2018-01-15 10:21:04 -05:00
create an issue. This issue should (preferably in the title) mention the
controller or endpoint and include the appropriate labels (`database`,
`performance` , and at least a team specific label such as `Discussion` ).
2021-03-16 14:11:53 -04:00
After the issue has been created, you can disable query limits on the code in question. For
2018-01-15 10:21:04 -05:00
Rails controllers it's best to create a `before_action` hook that runs as early
as possible. The called method in turn should call
2021-03-16 14:11:53 -04:00
`Gitlab::QueryLimiting.disable!('issue URL here')` . For example:
2018-01-15 10:21:04 -05:00
```ruby
class MyController < ApplicationController
2021-03-16 14:11:53 -04:00
before_action :disable_query_limiting, only: [:show]
2018-01-15 10:21:04 -05:00
def index
# ...
end
def show
# ...
end
2021-03-16 14:11:53 -04:00
def disable_query_limiting
Gitlab::QueryLimiting.disable!('https://gitlab.com/gitlab-org/...')
2018-01-15 10:21:04 -05:00
end
end
```
By using a `before_action` you don't have to modify the controller method in
question, reducing the likelihood of merge conflicts.
For Grape API endpoints there unfortunately is not a reliable way of running a
2022-05-24 08:09:04 -04:00
hook before a specific endpoint. This means that you have to add the allowlist
2018-01-15 10:21:04 -05:00
call directly into the endpoint like so:
```ruby
get '/projects/:id/foo' do
2021-03-16 14:11:53 -04:00
Gitlab::QueryLimiting.disable!('...')
2018-01-15 10:21:04 -05:00
# ...
end
```