이 글은 PHP opcache에 대한 관련 지식을 제공합니다. 주로 OPCache 기능을 이해하고 사용하는 방법에 대해 설명합니다. 관심 있는 친구들은 아래를 살펴보세요.
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 스크립트를 실행합니다. 반환됨
Worker(php-cgi) 프로세스가 PHP 스크립트를 실행합니다. 시간이 초과되면 504 오류가 반환됩니다.
처리가 완료되고 결과가 반환됩니다.
5단계: PHP -FPM Worker => Master => Nginx
PHP-FPM Worker 프로세스는 처리 결과를 반환하고 연결을 닫은 후 다음 요청을 기다립니다.
PHP-FPM Master 프로세스는 다음을 통해 처리 결과를 반환합니다. Socket
Nginx Handler는 각 응답 버퍼를 첫 번째 필터 → 두 번째 필터 → 등등으로 순차적으로 전송 → 최종 응답을 클라이언트로 전송
1.2 PHP 스크립트 설명 및 실행 메커니즘
이해한 후 PHP + Nginx의 전반적인 처리 흐름, PHP 스크립트의 구체적인 실행 흐름을 살펴보겠습니다. 먼저 예를 살펴보겠습니다.
<p><?php <br> if (!empty($_POST)) {<br> echo "Response Body POST: ", json_encode($_POST), "\n";<br> }<br> if (!empty($_GET)) { <br> echo "Response Body GET: ", json_encode($_GET), "\n";<br> }<br></p>실행 프로세스를 분석해 보겠습니다.
1.php는 실행 링크를 초기화합니다. , Zend 엔진을 시작하고 등록된 확장 모듈을 로드합니다
2. 초기화 후 스크립트 파일을 읽고 Zend 엔진은 스크립트 파일에 대한 어휘 분석(lex), 구문 분석(bison), 구문 트리 생성
3을 수행합니다. .Zend 엔진은 구문 트리를 컴파일하고 opcode를 생성합니다.
4.Zend 엔진은 opcode를 실행하고 실행 결과를 반환합니다
PHP cli 모드에서는 PHP 스크립트가 실행될 때마다 4단계가 순서대로 실행됩니다.
PHP-FPM 모드에서는 , 1) 단계는 PHP-FPM 시작 시 한 번 실행되며 이후 요청에서는 실행되지 않습니다. 2)~4) 단계는 각 요청마다 한 번씩 실행되어야 합니다.
실제로는 2) 단계에서 생성된 구문 트리와 opcode가 있습니다. 3) 동일한 PHP 스크립트가 실행될 때마다 동일한 결과를 얻게 됩니다. PHP-FPM 모드에서는 각 요청을 처리해야 하는데 이는 시스템 리소스를 크게 낭비하므로 최적화할 수 있는 방법이 있습니까?
물론 다음과 같은 것들이 있습니다:
OPCache: 이전에는 Zend Optimizer+로 알려져 있었으며 Zend Server의 오픈 소스 구성 요소이므로 적극 권장됩니다.
APC: 대체 PHP 캐시는 개방형입니다. PHP 중간 코드를 캐시하고 최적화하는 데 사용되는 무료 PHP opcode 캐싱 구성 요소; 더 이상 업데이트되지 않으며 권장되지 않습니다
APCu: APC의 분기이며 메모리를 공유하고 사용자 데이터를 캐시하며 opcode를 캐시할 수 없으며 사용할 수 있습니다. with Opcache
eAccelerate: 동일 더 이상 업데이트되지 않으며 권장되지 않습니다.
이렇게 하면 매번 PHP 스크립트를 로드하고 구문 분석하는 오버헤드가 제거됩니다. OPcache 확장은 PHP 5.5.0 및 후속 버전에 번들로 포함되어 있습니다.
두 가지 유형의 콘텐츠가 캐시됩니다.OPCode
설명, 변수 이름 등과 같은 내부 문자열
Puting 다른 프로세스가 액세스할 수 있도록 작업 코드를 공유 메모리로 컴파일했습니다. 여기에는 메모리 공유 메커니즘이 포함됩니다. 또한 모든 메모리 리소스 작업에는 잠금 문제가 하나씩 설명됩니다.
UNIX/Linux 시스템은 프로세스 간에 메모리를 공유하는 다양한 방법을 제공합니다.
1. System-V shm API: System V 공유 메모리
sysv shm은 프로세스에 의해 명시적으로 삭제되지 않는 한 항상 메모리에 존재합니다. , 시스템이 종료될 때까지;
2.mmap API:
mmap으로 매핑된 메모리는 지속되지 않습니다. 프로세스가 종료되면 미리 파일에 매핑되지 않으면 매핑이 무효화됩니다.
메모리 매핑 메커니즘 mmap은 익명 매핑과 파일 매핑의 두 가지 유형이 있습니다. mmap의 장점 중 하나는 파일을 프로세스의 주소 공간에 매핑한다는 것입니다. 사용자 버퍼에서 커널 페이지 캐시로의 데이터 복사 프로세스
물론, 또 다른 장점은 빈번한 읽기/쓰기 시스템 호출이 필요하지 않다는 것입니다. POSIX API:
System V의 공유 메모리는 오래되었습니다. POSIX 공유 메모리는 더 간단하고 합리적으로 설계된 API의 사용을 제공합니다.3.2 뮤텍스 잠금
이로 인해 또 다른 문제가 발생합니다. 새로운 코드, 대규모 트래픽 시나리오, 캐시 opcode 작업을 수행하기 위한 프로세스 대기열은 반복적인 쓰기로 인해 리소스가 낭비됩니다.
4.OPCache 캐시 해석
OPCache는 PHP5.5 버전 이후 PHP 소스 코드로 패키징되어 함께 출시된 공식 Opcode 캐시 솔루션입니다.
스크립트 컴파일 프로세스를 저장하여 PHP 실행 효율성을 향상시킵니다. APC 확장을 사용하여 동일한 작업을 수행하는 경우 특히 PHP7에서는 OPCache를 대신 사용하는 것이 좋습니다.
4.1 OPCode
캐시 Opcache는 OPCode와 다음 내용을 캐시합니다:
PHP 스크립트에 관련된 함수
PHP 스크립트에 정의된 클래스
PHP 스크립트 파일 경로
PHP 스크립트 OPAr 레이
PHP 스크립트 자체 구조/내용
4.2 Interned String
은 만료 및 업데이트 전략이 있는 캐시입니다. OPCache의 업데이트 전략은 매우 간단합니다. 만료된 데이터는 Wasted로 설정됩니다. 설정된 값에 도달하면 캐시가 지워지고 캐시가 다시 작성됩니다.
참고: 트래픽이 많은 시나리오에서 캐시를 재구축하는 것은 리소스를 많이 소모하는 작업입니다. OPCache는 캐시를 생성할 때 다른 프로세스가 읽는 것을 방지하지 않습니다. 이로 인해 많은 수의 프로세스가 반복적으로 새 캐시를 생성하게 됩니다. 그러므로 OPCache 만료 시간을 설정하지 마세요
새 코드가 출시될 때마다 캐시가 반복적으로 생성됩니다. 그것을 피하는 방법?
코드 워밍업(예: 스크립트를 사용하여 PHP 액세스 URL을 일괄 조정하거나 다음에서 제공하는 API 사용) 컴파일 캐시용 opcache_compile_file()과 같은 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_per 백분율= 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_commentsboolean 비활성화하면 파일에 댓글이 있어도 댓글 내용이 로드되지 않습니다. 이 옵션은 opcache.save_comments와 함께 사용하여 요청 시 주석 내용을 로드할 수 있습니다.
opcache.fast_shutdown boolean 활성화되면 빠른 중지 재개 이벤트가 사용됩니다. 소위 빠른 중지 재개 이벤트는 할당된 각 메모리 블록을 순차적으로 해제하는 대신 Zend 엔진을 사용하여 요청된 모든 변수의 메모리를 한 번에 해제하는 메모리 관리 모듈을 나타냅니다.
6.4 2차 수준 캐시 구성
opcache.file_cache 2차 수준 캐시 디렉터리를 구성하고 2차 수준 캐시를 활성화합니다. 두 번째 수준 캐시를 활성화하면 SHM 메모리가 가득 차거나, 서버가 다시 시작되거나, SHM이 재설정될 때 성능이 향상될 수 있습니다. 기본값은 파일 기반 캐싱을 비활성화하는 빈 문자열 ""입니다.
opcache.file_cache_onlyboolean 공유 메모리에서 opcode 캐싱을 활성화 또는 비활성화합니다.
opcache.file_cache_consistency_checksboolean 파일 캐시에서 스크립트를 로드할 때 파일의 체크섬을 확인할지 여부입니다.
opcache.file_cache_fallbackboolean Windows 플랫폼에서는 프로세스가 공유 메모리에 연결할 수 없을 때 파일 기반 캐싱이 사용됩니다. 즉, opcache.file_cache_only=1입니다. 파일 캐싱을 명시적으로 활성화해야 합니다.
추천 학습: "PHP 비디오 튜토리얼"
위 내용은 PHP opcache의 원리와 사용법을 자세히 설명하는 기사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
