PHP OPcache 적용 전후를 같은 조건으로 측정하는 방법

OPcache를 켰다는 설정만으로 성능 개선을 단정할 수는 없다. 실제 요청을 처리하는 Web SAPI에서 활성 상태를 확인하고, 같은 URL과 동시성으로 반복 측정해야 설정 효과와 우연한 변동을 구분할 수 있다.

CLI와 웹 실행 환경을 구분하기

php -i는 CLI 설정을 보여줄 수 있어 PHP-FPM이나 Apache 모듈의 상태와 다를 수 있다. 실제 웹 요청 경로에서 opcache_get_status(false)를 호출하되, 전체 스크립트 목록이나 서버 경로를 공개하지 않도록 필요한 값만 출력한다.

<?php
header('Content-Type: application/json; charset=utf-8');
$status = opcache_get_status(false);

echo json_encode([
    'enabled' => $status !== false,
    'cache_full' => $status['cache_full'] ?? null,
    'hits' => $status['opcache_statistics']['hits'] ?? null,
    'misses' => $status['opcache_statistics']['misses'] ?? null,
], JSON_PRETTY_PRINT);

이 상태 페이지는 인증 또는 내부 IP 제한 뒤에서만 사용하고, 확인이 끝나면 삭제한다. phpinfo() 전체 화면은 환경 변수와 경로 등 불필요한 정보를 노출할 수 있으므로 캡처 대상으로 삼지 않는다.

cold와 warm 측정 조건 고정하기

비교 실험에서는 코드, 데이터, URL, 요청 수, 동시성, 네트워크 위치를 고정한다. 첫 실행은 파일과 프로세스 캐시의 영향을 받으므로 cold 결과와 충분히 예열한 warm 결과를 분리하고, 평균보다 이상치에 덜 민감한 중앙값을 함께 기록한다.

1. 스테이징의 동일 URL을 대상으로 OPcache 비활성 상태를 3회 이상 측정한다.
2. Web SAPI 설정에서 OPcache를 활성화하고 PHP-FPM 등 해당 프로세스를 안전하게 재시작한다.
3. 상태 페이지에서 enabled, cache_full, hits와 misses를 확인한다.
4. 같은 부하 조건으로 cold 1회와 warm 3회 이상을 측정한다.
5. 중앙 응답 시간, 상위 지연 시간, 처리량, 오류 수와 hit 비율을 나란히 기록한다.

결과를 판정하는 기준

응답 시간이 줄더라도 오류가 늘거나 CPU·메모리 사용량이 허용 범위를 넘으면 성공으로 보지 않는다. 차이가 실행 간 편차보다 작다면 효과가 확인되지 않은 것으로 기록하고, 트래픽과 코드 규모가 더 현실적인 환경에서 다시 측정한다.

OPcache 상태와 측정값이 맞지 않을 때

OPcache를 켰는데 enabled가 false다

CLI가 아닌 Web SAPI용 php.ini를 수정했는지, 필요한 확장이 로드됐는지, 설정 변경 후 해당 프로세스를 재시작했는지 확인한다.

hits가 증가하지 않는다

매번 다른 스크립트를 호출하거나 프로세스가 계속 재시작되는지 살핀다. 캐시가 가득 찼다면 메모리 사용량과 cached scripts 수를 확인한 뒤 용량을 조정한다.

측정값이 실행할 때마다 크게 다르다

원격 네트워크, DB 상태, 백그라운드 작업과 자동 확장을 통제한다. 조건을 통제할 수 없다면 횟수를 늘리고 각 실행 조건을 결과와 함께 남긴다.

측정 기록 체크리스트

• Web SAPI에서 OPcache 상태를 확인했는가?
• URL, 요청 수, 동시성과 데이터 조건이 같은가?
• cold와 warm 실행을 분리했는가?
• 중앙값, 오류 수와 cache hit를 함께 기록했는가?

참고 문서

• PHP Manual — OPcache
• PHP Manual — opcache_get_status

한 줄 요약

OPcache 효과는 Web SAPI의 실제 활성 상태를 확인하고 동일한 조건의 cold·warm 측정을 반복해야 판단할 수 있다.