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)를 사용하지 마세요. 미들웨어는 요청 경로만을 고려하며 쿼리 매개변수를 무시합니다. 모든 매개변수는 요청 경로에 포함되어야 합니다. 이렇게 함으로써 쿼리 매개변수 순서 문제를 피하고 경로 일치를 쉽게 만듭니다.
자세한 정보는 다음을 참조하십시오:
도움말