PHP FastCGI 프로세스 관리자 PHP-FPM 아키텍처

마스터 프로세스는 여러 풀을 지원합니다. 각 풀은 서로 다른 포트의 마스터 프로세스에 의해 모니터링됩니다.
각 작업자 프로세스가 내장되어 있습니다. PHP 인터프리터와 프로세스는 백그라운드에 상주하며 프리포크의 동적 추가를 지원합니다.
각 작업자 프로세스는 런타임 시 스크립트 컴파일과 생성된 opcode를 메모리에 캐싱하여 성능을 향상시킵니다.
각 작업자 프로세스는 지정된 수의 요청에 응답한 후 자동으로 다시 시작하도록 구성을 지원합니다.
각 작업자 프로세스는 MySQL/ Memcached/Redis 영구 연결은 "연결 풀"을 구현하여 반복적인 연결 설정을 방지하고 프로그램에 투명합니다.
데이터베이스 영구 연결을 사용할 때는 고정된 수의 작업자 프로세스를 설정해야 하며 그렇지 않습니다. 동적 프리포크 모드를 사용합니다. 마스터 프로세스는 epoll 모델을 사용하여 요청을 비동기적으로 수신 및 배포하고 수신 포트를 수신하며 epoll_wait는 연결을 기다립니다.
그런 다음 이를 해당 풀의 작업자 프로세스에 배포하고 작업자 프로세스는 요청을 수락합니다. 사후 폴링이 연결을 처리합니다.
작업자 프로세스가 충분하지 않으면 마스터 프로세스가 더 많은 프로세스를 사전 포크합니다.
prefork가 pm.max_children 상한에 도달하면 모든 작업자 프로세스가 Busy 상태가 됩니다.
이때 마스터 프로세스는 연결 대기열 백로그에서 요청을 정지합니다. (기본값은 511)
1개의 PHP-FPM 작업자 프로세스에서 한 번에 하나의 요청만 처리할 수 있습니다.
기본 최대 개수입니다. MySQL의 max_connections 연결 수는 151입니다.
PHP-FPM 작업자 프로세스 수가 151개를 초과하지 않는 한 MySQL에 연결할 수 없는 상황이 발생하지 않습니다.
그리고 일반적인 상황에서는 그렇게 많은 PHP-FPM 작업 프로세스를 열 필요가 없습니다.
예를 들어 4개의 PHP- FPM 프로세스는 최대 4개의 CPU 코어를 실행할 수 있습니다. .
그렇다면 40개의 PHP-FPM 프로세스를 열어도 소용이 없습니다.
더 많은 메모리를 차지하게 되어 더 많은 CPU 컨텍스트 전환이 발생하고 성능이 저하됩니다.
각 요청에 대해 반복적으로 연결을 설정하고 해제하는 오버헤드를 줄이기 위해 영구 연결을 활성화할 수 있습니다.
PHP-FPM 프로세스는 다음과 같은 긴 연결을 유지합니다. MySQL은 투명한 "연결 풀"을 구현합니다.
Nginx는 실제로 좋은 분리인 PHP-FPM과 분리되어 있으며, PHP-FPM은 특히 PHP 요청 처리를 담당합니다. 하나의 PHP 요청.
페이지의 정적 리소스에 대한 모든 요청은 Nginx에 의해 처리되므로 Nginx가 가장 잘하는 것은 높은 수준의 동시성을 처리하는 것입니다.
PHP-FPM은 Apache의 프리포크 프로세스 모델과 유사한 다중 프로세스 FastCGI 서비스입니다.
이 모델은 PHP 요청만 처리하는 데 매우 효율적이고 안정적입니다. >Apache(libphp.so)와 달리 한 페이지는 그림, 스타일 시트, JS 스크립트, PHP 스크립트 등을 포함한 여러 요청을 처리해야 합니다.
php-fpm은 5.3부터 PHP 소스코드 트렁크만 들어가고, 이전 버전에는 php-fpm이 없었습니다.
당시spawn-fcgi는 php-cgi 프로세스 관리자를 호출해야 하는 FastCGI였는데,
또한 Apache의 mod_fcgid와 IIS의 PHP Manager도 php-cgi 프로세스를 호출해야 합니다.
그러나 php-fpm은 php에 전혀 의존하지 않습니다. - cgi는 완전히 독립적으로 실행되며 php(cli) 명령줄 해석기에 의존하지 않습니다.
php-fpm은 php 해석기가 내장된 FastCGI 서비스이므로 php를 읽을 수 있습니다. ini 구성과 php-fpm.conf 구성
개인적으로는 PHP-FPM 작업 프로세스 수를 CPU 코어 수의 2배로 설정하면 충분하다고 생각합니다. MySQL, Memcached, Redis, Linux 디스크 캐시(버퍼/캐시) 서비스에 메모리를 할당하는 것이 확실히 더 적합합니다.
과도한 PHP-FPM 프로세스는 오버헤드를 증가시킵니다.
PHP 코드에서는 긴 네트워크 I/O 시간 소모 코드를 유발할 수 있는 컬 또는 file_get_contents를 피해야 합니다.
프로세스가 오랫동안 차단되는 것을 방지하려면 CURLOPT_CONNECTTIMEOUT_MS 시간 제한을 주의 깊게 설정하세요.
장시간 작업을 비동기식으로 실행하려면 pclose(popen('/path/to/ task.php &', 'r')); 처리할 프로세스를 열려면
또는 메시지 대기열을 사용하세요. 즉, PHP-FPM 작업 프로세스를 차단하지 마세요.
php-fpm.conf에서 request_slowlog_timeout을 1초로 설정하고 Slowlog에서 확인하세요. 1초 이상 걸리는 코드도 있나요?
코드를 최적화하면 부담을 줄일 수 있나요? 모든 PHP-FPM 작업 프로세스는 성능을 향상시키는 근본적인 방법입니다.
CPU를 전체 로드로 실행하는 작업은 CPU 집약적인 작업으로 간주될 수 있습니다.
업로드 및 다운로드는 주로 네트워크 I/O 및 디스크 I/O에서 시간이 많이 소요되므로
PHP 인증이 필요한 다운로드 작업은 I/O 집약적인 작업입니다. Nginx의 AIO 스레드 풀에 위임됨:
header("X-Accel-Redirect: $file_path" );예를 들어 업로드 작업의 경우 포트 9001을 수신하는 upload라는 PHP-FPM 프로세스 풀을 생성할 수 있습니다.
는 특히 업로드 작업 처리를 담당합니다(Nginx를 통해 배포됨). ) 업로드를 피하기 위해 포트 9000에서 수신 대기하는 계산 집약적인 www 프로세스 풀에 대한 작업이 차단됩니다.
이때 업로드 프로세스 풀에서 더 많은 프로세스를 열어도 상관 없습니다.
[www]
listen = 127.0.0.1:9000
pm = static
pm. max_children = 4
[업로드]
listen = 127.0.0.1:9001
pm = 동적
pm.max_children = 8
pm.start_servers=4 풀을 격리하면 컴퓨팅 집약적인 작업과 I/O 집약적인 작업이 분리되어 전체 PHP 애플리케이션에 대한 차단의 영향을 줄일 수 있습니다. .
이 기사는 원래 오픈 소스 중국 블로그 eechen에서 작성되었습니다.
위 내용은 PHP FastCGI 프로세스 관리자 PHP-FPM의 아키텍처를 소개하며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.