계층별로 최적화하세요 — 각 계층은 부하가 다음 계층에 닿기 전에 흡수합니다. 목표는 대부분의 요청을 cache에서 제공하고 PHP와 데이터베이스가 가능한 한 적게 일하게 하는 것입니다.
1. PHP-FPM과 OPcache
풀을 RAM에 맞게 사이징하고, 를 켜서 PHP가 매 요청마다가 아니라 한 번만 컴파일되게 하세요:
; php-fpm pool: RAM이 고갈되지 않도록 worker 상한 설정
; pm.max_children = (PHP용 가용 RAM) / (평균 프로세스 크기, ~50MB)
pm = dynamic
pm.max_children = 40 ; 동시 PHP worker 하드 상한
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; memory leak 방지를 위해 worker 재활용
; OPcache: 컴파일된 bytecode를 메모리에 cache
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; prod에서 file-stat 검사 생략 (deploy 시 flush)
max_children가 너무 높으면 swap하고 crash하며; 너무 낮으면 요청이 큐에 쌓입니다(부하 시 502).
이 계층화 덕분에 홈페이지 접속이 PHP나 DB를 전혀 건드리지 않고 edge나 page cache에서 반환될 수 있습니다.
slow query log를 켜서 원인을 찾고, 커스텀 query에 index를 추가하고, autoloaded options를 점검하세요(autoload = yes인 wp_options는 모든 요청에서 로드됩니다 — 비대해진 autoload 데이터는 전부를 느리게 합니다). 마지막으로 플러그인 비대화를 줄이세요: 각 플러그인은 query와 PHP 작업을 더하므로, 쓰지 않는 것은 제거하세요.
WordPress 요청은 기본적으로 PHP와 DB 부하가 큽니다. 따라서 튜닝 없이는 트래픽에 무너집니다. 계층형 캐싱(OPcache → object cache → page cache → CDN)에 적절히 사이징된 PHP-FPM과 가벼운 데이터베이스를 더하면 단일 서버가 수십 배의 트래픽을 처리하고 — 스파이크 중에도 계속 가동되게 합니다.