ETag 캐싱을 이용한 폴링

변경 사항을 폴링하는 것은(서버에 새로운 변경 사항이 있는지 반복적으로 요청하는 것은)

GitLab 인스턴스에 높은 부하를 초래합니다. 이는 대개 최소한 몇 개의 SQL 쿼리를 실행해야 하기 때문입니다.

이로 인해 대규모 GitLab 인스턴스(예: GitLab.com) 확장이 매우 어려워지므로,

우리는 데이터베이스에 영향을 미치고 폴링을 요구하는 새로운 기능을 추가하는 것을 허용하지 않습니다.

대신 Redis에서 ETag 캐싱을 이용한 폴링 메커니즘을 사용해야 합니다.

사용 방법

  1. 폴링할 엔드포인트의 경로를 Gitlab::EtagCaching::Router에 추가합니다.

  2. 응답에 대한 폴링 간격 헤더를 Gitlab::PollingInterval.set_header로 설정합니다.

  3. 엔드포인트의 경로에 대해 Gitlab::EtagCaching::Store를 사용하여 캐시 무효화를 구현합니다.

    리소스가 변경될 때마다 이 리소스에 의존하는 경로의 ETag를 무효화해야 합니다.

  4. 메커니즘이 작동하는지 확인합니다:

    • 요청은 상태 코드 304를 반환해야 합니다.

    • log/development.log에 SQL 쿼리가 기록되어서는 안 됩니다.

작동 방식

캐시 미스:

Cache miss

캐시 히트:

Cache hit

  1. 리소스가 변경될 때마다 무작위 값을 생성하고 이를 Redis에 저장합니다.

  2. 클라이언트가 요청을 할 때 ETag 응답 헤더를 Redis의 값으로 설정합니다.

  3. 클라이언트는 응답을 캐시하고(클라이언트 측 캐싱) 같은 리소스에 대한 모든 이후 요청에 If-None-Match 헤더로 ETag를 전송합니다.

  4. If-None-Match 헤더가 현재 Redis의 값과 일치하면 리소스가 변경되지 않았음을 알 수 있으므로,

    데이터베이스를 전혀 쿼리하지 않고 즉시 304 응답을 보낼 수 있습니다. 클라이언트의 브라우저는 캐시된 응답을 사용합니다.

  5. If-None-Match 헤더가 현재 Redis의 값과 일치하지 않으면 리소스가 변경되었으므로

    새로운 응답을 생성해야 합니다.

ETag 캐싱을 활성화하려는 엔드포인트에는 쿼리 매개변수(예: ?scope=all)를 사용하지 마십시오.

미들웨어는 요청 경로만 고려하고 쿼리 매개변수는 무시합니다.

모든 매개변수는 요청 경로에 포함되어야 합니다.

이를 통해 쿼리 매개변수 정렬 문제를 피하고 경로 매칭을 쉽게 할 수 있습니다.

자세한 정보는 다음을 참조하세요: