ETag 캐싱을 사용한 폴링
변경 사항을 반복하여 서버에 요청하는 폴링은 일반적으로 몇 개의 SQL 쿼리를 실행해야 하기 때문에 GitLab 인스턴스에 높은 부하를 유발합니다. 이는 GitLab.com과 같이 대규모 GitLab 인스턴스의 확장을 매우 어렵게 만들며, 따라서 데이터베이스를 히트하는 폴링을 요구하는 새로운 기능을 추가하는 것을 허용하지 않습니다.
대신 Redis에서 ETag 캐싱과 함께 폴링 메커니즘을 사용해야 합니다.
사용 방법
- 폴링하려는 엔드포인트의 경로를
Gitlab::EtagCaching::Router에 추가합니다. - 응답에 대한 폴링 간격 헤더를
Gitlab::PollingInterval.set_header로 설정합니다. -
Gitlab::EtagCaching::Store를 사용하여 엔드포인트의 캐시 무효화를 구현합니다. 리소스가 변경될 때마다 이 리소스에 종속된 경로의 ETag를 무효화해야 합니다. - 메커니즘이 작동하는지 확인하세요:
- 요청은 상태 코드 304를 반환해야 합니다.
-
log/development.log에 기록된 SQL 쿼리가 없어야 합니다.
작동 방식
캐시 미스:
캐시 히트:
- 리소스가 변경될 때마다 우리는 임의의 값을 생성하고 Redis에 저장합니다.
- 클라이언트가 요청을 보낼 때 우리는
ETag응답 헤더를 Redis의 값으로 설정합니다. - 클라이언트는 응답을 캐시하고 (클라이언트 측 캐싱) 동일한 리소스에 대한 후속 요청마다
If-None-Match헤더로 ETag를 보냅니다. -
If-None-Match헤더가 Redis의 현재 값과 일치하면 리소스가 변경되지 않았음을 알기 때문에 데이터베이스를 전혀 쿼리하지 않고 즉시 304 응답을 보낼 수 있습니다. 클라이언트의 브라우저는 캐시된 응답을 사용합니다. -
If-None-Match헤더가 Redis의 현재 값과 일치하지 않으면 리소스가 변경되었기 때문에 새로운 응답을 생성해야 합니다.
ETag 캐싱을 활성화하려는 엔드포인트에 대해 쿼리 매개변수(예: ?scope=all)를 사용하지 마십시오. 미들웨어는 요청 경로만을 고려하고 쿼리 매개변수를 무시합니다. 모든 매개변수는 요청 경로에 포함되어야 합니다. 이렇게 함으로써 쿼리 매개변수 순서 문제를 피하고 라우트 일치를 쉽게 만듭니다.
더 많은 정보는 아래 링크를 참고하세요:
도움말