Technote

성능 최적화 심화

Redis 오브젝트 캐시 적중률을 읽는 법 — 90%가 항상 좋은 것은 아니다

적중률 숫자 하나만 보고 캐시가 잘 돌고 있다고 판단하면, 정작 느린 화면은 그대로 남습니다. 어떤 키가 몇 번 조회되는지까지 내려가 봐야 병목이 보입니다.

wp redis status 가 보여 주는 적중률(hit ratio)은 사이트 전체의 평균입니다. 평균 90% 라는 말은 어딘가는 99% 이고 어딘가는 50% 라는 뜻일 수 있습니다. 캐시를 점검할 때 적중률은 출발점이지 결론이 아닙니다.

적중률이 높아도 느린 세 가지 경우

  • 미스가 비싼 곳에 몰려 있다 — 전체 요청의 5% 미스가 전부 무거운 옵션 · 메뉴 조회라면, 평균은 좋아도 관리자 화면은 느립니다.
  • 적중이 값싼 키에 몰려 있다 — 트랜션트 수천 건이 반복 적중해 비율을 끌어올리는 동안, 정작 무거운 쿼리는 캐시 대상이 아닐 수 있습니다.
  • 무효화가 잦다 — 저장할 때마다 그룹 전체가 비워지는 플러그인이 있으면, 편집이 활발한 시간대만 느려집니다.
계층마다 책임이 하나 — 적중률은 두 번째 층의 이야기일 뿐이다

키 단위로 내려가는 법

Query Monitor 의 오브젝트 캐시 패널이 요청 한 번의 그룹별 적중/미스를 보여 줍니다. 여기서 봐야 할 것은 비율이 아니라 미스가 난 그룹의 이름입니다. options 그룹 미스가 많으면 autoload 문제를, posts 미스가 많으면 쿼리 설계를 의심합니다.

# 지금 Redis 에 어떤 키가 많은가 (운영 중에는 SCAN — KEYS 금지)
redis-cli --scan --pattern 'wper_*' | head -50

# 그룹별 메모리 상위
redis-cli --bigkeys

점검 순서

  1. wp redis status — 연결 · 드롭인부터. Drop-in: Valid 가 아니면 이하 전부 무의미합니다.
  2. Query Monitor 로 느린 화면 하나를 골라 그 요청의 미스 그룹을 봅니다.
  3. 미스 그룹이 매 요청 같은 키면 무효화 주기를, 매번 다른 키면 캐시 키 설계를 봅니다.
  4. 고치고 나서 같은 화면을 같은 조건으로 다시 잽니다 — 전/후가 같은 조건이 아니면 개선은 증명되지 않습니다.

페이지 캐시와 오브젝트 캐시의 역할 분리는 FastCGI 캐시 우회 규칙에서 이어서 다룹니다. 캐시 계층 설계를 포함한 성능 작업 전체는 최적화 지원 사업의 범위입니다.

이 주제의 다른 글

노하우 목록으로

성능 최적화 실무

태그 하나가 더하는 밀리초는 누가 냅니까

추적 스크립트는 내려받고 끝나지 않습니다. 파싱과 실행이 메인 스레드를 점유하는 동안 페이지는 손가락에 반응하지 않습니다. 그 비용은 직접 잴 수 있습니다.

마케터 3분 읽기

₩270,000 · 신청하기