집 >백엔드 개발 >PHP 튜토리얼 >PHP Opcache 작동 방식에 대한 심층 분석

PHP Opcache 작동 방식에 대한 심층 분석

藏色散人앞으로: 2022-01-05 14:01:444292검색

PHP 프로젝트, 특히 동시성이 높고 트래픽이 많은 시나리오에서 PHP의 응답 시간을 향상시키는 방법은 매우 중요한 작업입니다.

Opcache는 특히 PHP 프레임워크를 적용하는 프로젝트에서 PHP 성능을 최적화하는 데 없어서는 안 될 구성 요소입니다.

1. 개요

OPCache 기능을 이해하기 전에 먼저 PHP-FPM + Nginx의 작동 메커니즘과 PHP 스크립트 해석 및 실행 메커니즘을 이해해야 합니다.

1.1 PHP-FPM + Nginx의 작동 메커니즘

요청은 웹 브라우저에서 Nginx로 이동한 다음 PHP 처리로 이동합니다.

1단계: 서비스 시작.

PHP-FPM을 시작하세요. PHP-FPM은 TCP 소켓과 Unix 소켓의 두 가지 통신 모드를 지원합니다.
PHP-FPM은 두 가지 유형의 프로세스를 시작합니다. 전자는 포트 모니터링, 작업 할당 및 작업을 담당합니다. 작업자 프로세스 관리. 후자는 PHP 스크립트 해석, 컴파일 및 실행을 담당하는 PHP의 cgi 프로그램입니다.
Nginx를 시작하세요. 먼저 ngx_http_fastcgi_module 모듈이 로드되어 FastCGI 실행 환경을 초기화하고 FastCGI 프로토콜 요청 프록시를 구현합니다.
참고: fastcgi 작업자 프로세스(cgi 프로세스)는 Nginx가 아닌 PHP-FPM에 의해 관리됩니다. Nginx는 단지 프록시입니다

2단계: 요청 => Nginx

Nginx는 요청을 수신하고 위치 구성에 따라 적합한 핸들러를 선택합니다
다음은 PHP 프록시를 위한 핸들러입니다

3단계: Nginx => PHP-FPM

Nginx는 요청을 fastcgi 요청
으로 변환하고 이를 TCP 소켓/Unix 소켓

을 통해 PHP-FPM의 마스터 프로세스로 보냅니다. 4단계: PHP-FPM 마스터 = > Worker

PHP-FPM 마스터 프로세스는 요청을 수신하고
작업자 프로세스를 할당하여 PHP 스크립트를 실행합니다. 유휴 작업자가 없으면 502 오류가 반환됩니다
Worker(php- cgi) 프로세스는 시간이 초과되면 PHP 스크립트를 실행하고 504 오류를 반환
처리가 완료되면 결과를 반환합니다

5단계: PHP-FPM 작업자 => 마스터 => Nginx

PHP -FPM Worker 프로세스는 처리 결과를 반환하고 연결을 닫습니다. 다음 요청을 기다리는 중
PHP-FPM Master 프로세스는 Socket을 통해 처리 결과를 반환합니다
Nginx Handler는 각 응답 버퍼를 첫 번째 필터 → 두 번째 → 순차적으로 보냅니다. on → 최종 응답이 클라이언트로 전송됩니다

1.2 PHP 스크립트 설명 및 실행 메커니즘

PHP + Nginx의 전반적인 처리 흐름을 이해한 후, PHP의 구체적인 실행 흐름을 살펴보겠습니다.

먼저 예를 살펴보겠습니다.

<?php
if (!empty($_POST)) {
    echo "Response Body POST: ", json_encode($_POST), "\n";
}

if (!empty($_GET)) {
    echo "Response Body GET: ", json_encode($_GET), "\n";
}

실행 프로세스를 분석해 보겠습니다.

php는 실행 링크를 초기화하고, Zend 엔진을 시작하고, 등록된 확장 모듈을 로드합니다
초기화 후 스크립트 파일을 읽고 Zend 엔진이 어휘 수행을 수행합니다. 스크립트 파일에 대한 분석(lex)), 문법 분석(BISON), 문법 트리 생성
zend 엔진이 구문 트리를 컴파일하고, OPCODE 생성,
zend 엔진 OPCODE 실행 , 실행 결과 반환

PHP cli 모드에서는 PHP 스크립트가 실행될 때마다 4단계가 순차적으로 실행됩니다.

PHP-FPM 모드에서는 1) 단계가 한 번 실행됩니다. PHP-FPM이 시작되고 이후 요청에서는 다시 실행되지 않습니다. 2)~4)단계는 각 요청마다 한 번씩 실행되어야 합니다;

실제로 2)와 3단계에서 생성된 구문 트리 및 opcode는 ), 동일한 PHP 스크립트는 실행될 때마다 동일한 결과를 갖게 됩니다.

PHP-FPM 모드에서는 각 요청을 한 번만 처리해야 하는데 이는 시스템 리소스를 엄청나게 낭비합니다. 그렇다면 최적화할 수 있는 방법이 있을까요?

물론 다음과 같은 것들이 있습니다:

OPCache: 이전에는 Zend Optimizer+로 알려져 있었으며 Zend Server 공식 제품의 오픈 소스 구성 요소이므로 적극 권장됩니다.
APC: Alternative PHP Cache는 개방형 무료 PHP opcode입니다. 캐싱에 사용되는 캐싱 구성 요소, PHP 중간 코드 최적화, 더 이상 업데이트되지 않으며 권장되지 않음
APCu: APC의 분기이며, 공유 메모리, 사용자 데이터 캐시, opcode를 캐시할 수 없음, Opcache
eAccelerate와 함께 사용할 수 있음: 또한 더 이상 업데이트되지 않으며 권장되지 않습니다
xCache: 더 이상

사용을 권장하지 않습니다. 2. OPCache 소개

OPCache는 Zend에서 공식적으로 제작한 무료 개방형 opcode 캐시 확장 프로그램입니다. 매번 PHP 스크립트를 로드하고 구문 분석할 필요가 없습니다.

OPcache 확장은 PHP 5.5.0 및 후속 버전에 번들로 포함되었습니다.

두 가지 유형의 콘텐츠 캐시:

OPCode
내부 문자열(예: 주석, 변수 이름 등)

3. OPCache 원칙

OPCache 캐싱의 주요 메커니즘은 다음과 같습니다.컴파일된 문자열을 넣습니다. 공유 메모리에 대한 opcode는 다른 프로세스가 액세스할 수 있도록 제공됩니다.

이에는 메모리 공유 메커니즘도 포함됩니다. 또한 모든 메모리 리소스 작업에는 잠금 문제가 있습니다.

3.1 공유 메모리

UNIX/Linux 시스템은 프로세스 간에 메모리를 공유하는 다양한 방법을 제공합니다.

System-V shm API: System V 공유 메모리,
- sysv shm은 프로세스가 아닌 한 지속됩니다. 명시적으로 삭제되지 않으면 시스템이 종료될 때까지 메모리에 항상 존재합니다.
mmap API:
- mmap 매핑된 메모리는 지속되지 않습니다. 프로세스가 종료되면 매핑이 유효하지 않게 됩니다. 파일에
- 메모리 매핑 메커니즘 mmap은 POSIX 표준 시스템 호출로 익명 매핑과 파일 매핑이 있습니다
- mmap의 가장 큰 장점은 파일을 프로세스의 주소 공간에 매핑한다는 것입니다.
- 사용자 버퍼에서 커널 페이지 캐시 버퍼의 복사 프로세스로 데이터를 전송할 필요가 없습니다.
- 물론 또 다른 장점은 빈번한 읽기/쓰기 시스템 호출이 필요하지 않다는 것입니다.
POSIX API: System V의 공유 메모리는 구식이며, POSIX 공유 메모리는 더 간단하고 합리적으로 설계된 API를 제공합니다.
Unix 소켓 API

OPCache는 구성 또는 기본 mmap 메모리 공유 모드에 따라 처음 세 가지 공유 메모리 메커니즘을 사용합니다.

PHP 바이트코드 캐싱 시나리오를 기반으로 OPCache의 메모리 관리 설계는 매우 간단하며 빠른 읽기 및 쓰기, 메모리 해제 없음, 만료된 데이터가 낭비됨으로 설정됩니다.

낭비된 메모리가 설정 값보다 크면 OPCache 메커니즘이 자동으로 다시 시작되고 캐시가 지워지고 재생성됩니다.

3.2 뮤텍스 잠금

모든 메모리 리소스 작업에는 잠금 메커니즘이 포함됩니다.

공유 메모리: 단위 시간에 하나의 프로세스만 쓰기 작업을 수행할 수 있으며 여러 프로세스가 읽기 작업을 수행할 수 있습니다.

쓰기 작업은 동시에 수행되며 읽기 작업이 차단되지 않습니다. 잠금 상태가 되는 경우는 거의 없습니다.

이로 인해 또 다른 문제가 발생합니다. 새로운 코드, 대규모 트래픽 시나리오, 캐시 opcode 작업을 수행하기 위한 프로세스 대기열은 반복적인 쓰기로 인해 리소스가 낭비됩니다.

4.OPCache 캐시 해석

OPCache는 PHP5.5 버전 이후 PHP 소스 코드로 패키징되어 함께 출시된 공식 Opcode 캐시 솔루션입니다.

PHP 컴파일로 생성된 바이트코드와 데이터를 공유 메모리에 캐시합니다. 각 요청마다 컴파일된 opcode를 캐시에서 직접 읽어 실행합니다.

스크립트 컴파일 프로세스를 저장하여 PHP 실행 효율성을 향상시킵니다.

APC 확장을 사용하여 동일한 작업을 수행하는 경우 특히 PHP7에서는 OPCache를 대신 사용하는 것이 좋습니다.

4.1 OPCode 캐시

Opcache는 OPCode와 다음 콘텐츠를 캐시합니다.

PHP 스크립트에 포함된 함수
PHP 스크립트에 정의된 클래스
PHP 스크립트 파일 경로
PHP 스크립트 OPArray
PHP 스크립트의 자체 구조/내용

4.2 인터네디드 문자열 캐시

먼저 해야 할 일 이해하세요, Interned String이 무엇인가요?

PHP5.4에서는 PHP의 문자열 저장 및 처리를 최적화하기 위해 Interned String 메커니즘이 도입되었습니다.

특히 PHP 문서와 같이 큰 문자열 덩어리를 처리할 때 Interned String은 메모리를 최적화할 수 있습니다.

내부 문자열 캐시 콘텐츠에는 변수 이름, 클래스 이름, 메서드 이름, 문자열, 주석 등이 포함됩니다.

PHP-FPM 모드에서 Interned String 캐시 문자는 작업자 프로세스 내로 제한됩니다.

OPCache에 캐시된 경우 Interned String 캐시된 문자열을 작업자 프로세스 간에 사용하여 메모리를 절약할 수 있습니다.

한 가지에 주의해야 합니다. PHP 개발에는 일반적으로 OPCache에도 캐시되는 많은 주석 섹션이 있습니다.

php.ini 구성을 통해 댓글 캐싱을 끌 수 있습니다.

그러나 Zend Framework와 같은 프레임워크에서는 이 주석을 참조하므로 주석 캐싱을 끌지 여부를 다르게 처리해야 합니다.

5. OPCache 업데이트 전략

은 만료 및 업데이트 전략이 있는 캐시입니다.

OPCache의 업데이트 전략은 매우 간단합니다. 만료된 데이터는 낭비됨으로 설정됩니다. 설정된 값에 도달하면 캐시가 지워지고 캐시가 다시 빌드됩니다.

참고 사항: 트래픽이 많은 시나리오에서 캐시를 재구축하는 것은 리소스를 많이 소모하는 작업입니다.

OPCache는 캐시를 생성할 때 다른 프로세스가 읽는 것을 막지 않습니다.

이로 인해 많은 수의 프로세스가 반복적으로 새 캐시를 생성하게 됩니다. 따라서 OPCache 만료 시간을 설정하지 마세요

새 코드를 릴리스할 때마다 캐시가 반복적으로 생성됩니다. 그것을 피하는 방법?

피크 기간에는 코드를 공개하지 마세요 , 이는 어떤 상황에서도 따라야 하는 규칙입니다.
코드 워밍업(예: 스크립트를 사용하여 PHP 액세스 URL을 일괄 조정하거나 다음에서 제공하는 API 사용) opcache_compile_file()과 같은 OPCache 컴파일 캐싱 수행opcache_compile_file() 进行编译缓存

6. OPCache 的配置

6.1 内存配置

opcache.preferred_memory_model="mmap" OPcache 首选的内存模块。如果留空，OPcache 会选择适用的模块，通常情况下，自动选择就可以满足需求。可选值包括： mmap，shm, posix 以及 win32。
opcache.memory_consumption=64 OPcache 的共享内存大小，以兆字节为单位，默认64M
opcache.interned_strings_buffer=4 用来存储临时字符串的内存大小，以兆字节为单位，默认4M
opcache.max_wasted_percentage=5 浪费内存的上限，以百分比计。如果达到此上限，那么 OPcache 将产生重新启动续发事件。默认5

6.2 允许缓存的文件数量以及大小

opcache.max_accelerated_files=2000 OPcache 哈希表中可存储的脚本文件数量上限。真实的取值是在质数集合 { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 } 中找到的第一个大于等于设置值的质数。设置值取值范围最小值是 200，最大值在 PHP 5.5.6 之前是 100000，PHP 5.5.6 及之后是 1000000。默认值2000
opcache.max_file_size=0 以字节为单位的缓存的文件大小上限。设置为 0 表示缓存全部文件。默认值0

6.3 注释相关的缓存

opcache.load_comments boolean 如果禁用，则即使文件中包含注释，也不会加载这些注释内容。本选项可以和 opcache.save_comments 一起使用，以实现按需加载注释内容。
opcache.fast_shutdown

6. OPCache 구성

6.1 메모리 구성

🎜🎜 🎜opcache.preferred_memory_model="mmap" OPcache 기본 메모리 모듈. 공백으로 두면 OPcache는 해당 모듈을 선택하며 일반적으로 자동 선택으로 충분합니다. 선택적 값에는 mmap, shm, posix 및 win32가 포함됩니다. 🎜🎜opcache.memory_consumption=64 OPcache의 공유 메모리 크기(MB), 기본값 64M🎜🎜opcache.interned_strings_buffer=4 메모리 크기 임시 문자열을 저장하는 데 사용됩니다(MB 단위). 기본값은 4M🎜🎜opcache.max_wasted_percentage=5 낭비되는 메모리의 상한(%)입니다. 이 제한에 도달하면 OPcache는 다시 시작 이벤트를 생성합니다. 기본 5🎜🎜🎜🎜6.2 캐시가 허용되는 파일 수 및 크기🎜🎜🎜🎜🎜opcache.max_accelerated_files=2000 OPcache 해시 table 에 저장할 수 있는 최대 스크립트 파일 수입니다. 실수값은 소수 집합 { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 }에서 발견된 첫 번째 소수이며, 그보다 크거나 같습니다. 값을 설정합니다. 설정값의 최소값 범위는 200이고, PHP 5.5.6 이전의 최대값은 100000, PHP 5.5.6 이상은 1000000입니다. 코드> . 기본값 2000🎜🎜opcache.max_file_size=0 캐시의 최대 파일 크기(바이트)입니다. 모든 파일을 캐시하려면 0으로 설정합니다. 기본값 0🎜🎜🎜🎜6.3 댓글 관련 캐시 🎜🎜🎜🎜🎜opcache.load_comments boolean 비활성화하면 파일에 다음이 포함되어 있어도 댓글과 그 내용은 로드되지 않습니다. 이 옵션은 요청 시 주석 콘텐츠를 로드하기 위해 opcache.save_comments와 함께 사용할 수 있습니다. 🎜🎜opcache.fast_shutdown boolean 활성화되면 빠른 중지 재개 이벤트가 사용됩니다. 소위 빠른 중지 재개 이벤트는 할당된 각 메모리 블록을 순차적으로 해제하는 대신 Zend 엔진을 사용하여 요청된 모든 변수의 메모리를 한 번에 해제하는 메모리 관리 모듈을 나타냅니다. 🎜🎜🎜🎜🎜6.4 두 번째 수준 캐시 구성🎜🎜🎜

opcache.file_cache 두 번째 수준 캐시 디렉터리를 구성하고 두 번째 수준 캐시를 활성화합니다. 두 번째 수준 캐시를 활성화하면 SHM 메모리가 가득 차거나, 서버가 다시 시작되거나, SHM이 재설정될 때 성능이 향상될 수 있습니다. 기본값은 파일 기반 캐싱을 비활성화하는 빈 문자열 ""입니다. opcache.file_cache 配置二级缓存目录并启用二级缓存。启用二级缓存可以在 SHM 内存满了、服务器重启或者重置 SHM 的时候提高性能。默认值为空字符串 ""，表示禁用基于文件的缓存。
opcache.file_cache_only boolean 启用或禁用在共享内存中的 opcode 缓存。
opcache.file_cache_consistency_checks boolean 当从文件缓存中加载脚本的时候，是否对文件的校验和进行验证。
opcache.file_cache_fallback boolean 在 Windows 平台上，当一个进程无法附加到共享内存的时候，使用基于文件的缓存，也即：opcache.file_cache_only=1

opcache.file_cache_only

boolean

opcache.file_cache_consistency_checks boolean 파일 캐시에서 스크립트를 로드할 때 파일의 체크섬을 확인할지 여부입니다. opcache.file_cache_fallback boolean Windows 플랫폼에서 프로세스가 공유 메모리에 연결할 수 없으면 파일 기반 캐시, 즉 opcache_only가 사용됩니다. =1. 파일 캐싱을 명시적으로 활성화해야 합니다.