성능 최적화 입문
고치기 전에 잽니다 — 최적화의 첫 30분
직관으로 최적화하면 대개 무언가는 좋아집니다. 문제는 그것이 병목이 아니었다는 점입니다. 구간을 나누고 숫자를 얻는 절차부터 정합니다.
Technote
느리다는 감각을 숫자로 바꾸는 과정. 어떤 쿼리와 어떤 훅이 시간을 쓰는지 찾아내고, 캐시 계층을 올바른 순서로 쌓는 방법을 다룹니다.
글 7편
성능 최적화 입문
직관으로 최적화하면 대개 무언가는 좋아집니다. 문제는 그것이 병목이 아니었다는 점입니다. 구간을 나누고 숫자를 얻는 절차부터 정합니다.
성능 최적화 입문
같은 화면에 나란히 나오지만 완전히 다른 문제입니다. 한쪽은 쿼리를 고쳐야 하고, 다른 한쪽은 캐시로 사라집니다. 구분이 먼저입니다.
성능 최적화 실무
WP_Query 는 자기 결과에 대해서만 캐시를 채웁니다. 손으로 만든 ID 목록에는 그 혜택이 따라오지 않고, 그 차이가 쿼리 수를 결정합니다.
성능 최적화 실무
반복되는 동일 조회는 사라집니다. 느린 쿼리 한 건은 그대로입니다. 이 구분을 모르면 캐시를 붙여 놓고 왜 안 빨라지는지 묻게 됩니다.
성능 최적화 실무
저장은 세 줄이면 됩니다. 어려운 것은 언제 지울 것인가이고, 지워야 할 사건은 최소 두 가지입니다. 하나만 놓쳐도 증상이 갈립니다.
서버 · 인프라 실무
완성된 HTML 을 보관하는 계층은 PHP 앞에 있어야 값을 합니다. 서버 캐시 위에 플러그인 캐시를 얹으면 무효화 타임라인이 둘이 됩니다.
성능 최적화 심화
autoload 로 표시된 옵션은 요청마다 한 번에 읽혀 역직렬화됩니다. 큰 값 하나가 사이트 전체에 조용히 세금을 매기는 구조입니다.