각 컨트롤러와 API 엔드포인트, Sidekiq 워커는 최대 100개의 SQL 쿼리를 실행할 수 있습니다. 100개가 넘는 SQL 쿼리가 실행되면 이는 반드시 수정해야 할 성능 문제 입니다.

실패하는 테스트 해결#

테스트 환경에서는 이 임계값을 초과하면 오류가 발생합니다.

100개가 넘는 SQL 쿼리를 실행해 테스트가 실패하는 경우 해결책은 두 가지가 있습니다.

• 실행되는 SQL 쿼리 수를 줄입니다.
• 해당 컨트롤러나 API 엔드포인트의 쿼리 제한을 일시적으로 비활성화합니다.

쿼리 제한 비활성화는 기존 컨트롤러나 엔드포인트가 원인이고 SQL 쿼리 수를 줄이는 데 많은 노력이 드는 경우에만 사용하는 최후의 수단입니다. 새로 추가하는 컨트롤러와 엔드포인트는 100개가 넘는 SQL 쿼리를 실행할 수 없으며, 이 규칙에는 예외가 없습니다.

파이프라인 안정성#

기본 브랜치 파이프라인에서 spec에 쿼리 제한 오류가 발생하기 시작하면 안내에 따라 쿼리 제한을 비활성화합니다. 제한을 비활성화할 때는 항상 이슈를 연결하고 우선순위를 지정해, 과도한 쿼리 수의 원인을 조사할 수 있도록 합니다.

쿼리 제한 비활성화#

컨트롤러의 쿼리 제한을 비활성화해야 한다면 먼저 이슈를 생성해야 합니다. 이 이슈에는 해당 컨트롤러나 엔드포인트를 가급적 제목에 언급하고, 적절한 레이블(database, performance, 그리고 Discussion과 같은 팀 전용 레이블 하나 이상)을 포함합니다.

GitLab 17.2부터 QueryLimiting.disable은 무제한이 아닌 새 임계값을 설정해야 합니다.

이슈를 생성한 뒤에는 해당 코드의 쿼리 제한을 비활성화할 수 있습니다. Rails 컨트롤러에서는 가능한 한 이른 시점에 실행되는 before_action 훅을 만드는 방식이 가장 좋습니다. 호출되는 메서드는 다시 Gitlab::QueryLimiting.disable!('issue URL here')을 호출합니다. 예를 들면 다음과 같습니다.

class MyController < ApplicationController
  before_action :disable_query_limiting, only: [:show]

  def index
    # ...
  end

  def show
    # ...
  end

  def disable_query_limiting
    Gitlab::QueryLimiting.disable!('https://gitlab.com/gitlab-org/...', new_threshold: 200)
  end
end

before_action을 사용하면 해당 컨트롤러 메서드를 수정하지 않아도 되므로 머지 충돌이 발생할 가능성이 줄어듭니다.

Grape API 엔드포인트에서는 특정 엔드포인트 앞에서 훅을 실행할 안정적인 방법이 없습니다. 따라서 다음과 같이 엔드포인트 안에 허용 목록 호출을 직접 추가해야 합니다.

get '/projects/:id/foo' do
  Gitlab::QueryLimiting.disable!('...', new_threshold: 200)

  # ...
end

Sidekiq 워커에서도 허용 목록을 직접 추가해야 합니다.

def perform(args)
  Gitlab::QueryLimiting.disable!('...', new_threshold: 200)

  # ...
end