이제 많은 클라우드 호스트 통합 환경이나 다양한 퍼블릭 클라우드가 기본적으로 lighttpd 또는 nginx 서버를 제공합니다. 이러한 고성능 서버 소프트웨어가 Apache를 대체하지 못한 이유는 무엇입니까?
이제 많은 클라우드 호스트 통합 환경이나 다양한 퍼블릭 클라우드가 기본적으로 lighttpd 또는 nginx 서버를 제공합니다. 이러한 고성능 서버 소프트웨어가 Apache를 대체하지 못한 이유는 무엇입니까?
Nginx는 확실히 Apache보다 가볍고 효율적이며 둘 다 매우 안정적입니다.
2016년 2월 Netcraft 통계에 따르면 가장 바쁜 100만 개 사이트 중 Apache가 약 46%를 차지하고 Nginx가 25%를 차지하며 IIS는 12% 미만이라는 점에 주목할 필요가 있습니다. 그 중 Nginx의 점유율은 약 25%를 기록하며 계속해서 상승 추세를 유지하고 있는 반면, Apache와 IIS는 모두 하락세를 보이고 있습니다. 즉, 동시성이 높은 웹사이트에서는 Tengine이 사용하는 추세입니다. 국내 알리바바는 Nginx의 2차 개발을 기반으로 한 브랜치입니다.
대부분의 가상 호스트 사용자에게는 대역폭이 병목 현상이기 때문에 높은 동시성은 의문의 여지가 없으며 2M 대역폭의 동시성은 말할 필요도 없습니다. 그리고 Apache는 구성에 과부하가 걸리지 않고 .htaccess 구성을 지원합니다. 용이성 구성이 Nginx보다 좋습니다. 즉, 동시성 시나리오를 추구하지 않는 경우 충분하고 쉬운 한 아키텍처를 변경해야 하는 이유는 Apache+PHP 아키텍처입니다.
Nginx는 Nginx 문제가 아니라 백엔드 문제로 인해 502 잘못된 게이트웨이 오류를 반환합니다.
예를 들어 요청을 처리하는 동안 백엔드 PHP-FPM 프로세스가 충돌하면 Nginx는 502 오류를 반환합니다. .
물론 fastcgi_next_upstream 구성을 사용하여 Nginx가 처리를 위해 요청을 다른 업스트림으로 전송하도록 할 수 있습니다. fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;
Nginx+PHP-FPM은 동적 및 정적 분리, 로드 밸런싱 및 장애 조치를 달성합니다. 이는 실제로 Apache보다 높은 동시성 시나리오에서 더 나은 이점이 있습니다.
PHP 모듈이 내장된 Apache 프로세스는 PHP를 처리할 때 정적 리소스를 처리할 수 없지만 Nginx는 PHP를 처리하는 작업이 필요하므로 이 문제에 대해 걱정할 필요가 없습니다. 동적과 정적을 분리하는 PHP-FPM의 문제입니다. 그리고 Nginx는 업스트림을 지원하여 PHP-FPM 클러스터를 구성하여 Apache가 잘 못하는 로드 밸런싱을 달성합니다.
Nginx와 결합된 PHP-FPM은 I/O 집약적인 작업을 분리하고 전체 PHP 애플리케이션에 대한 차단의 영향을 줄일 수도 있습니다.
사용자 다운로드 및 컬 요청은 일반적인 I/O 집약적인 작업이기 때문입니다. 주로 시간이 많이 소요되는 네트워크 I/O 및 디스크 I/O에서 발생합니다.
PHP 인증이 필요한 다운로드 작업은 Nginx의 AIO 스레드 풀에 위임할 수 있습니다.header("X-Accel-Redirect: $filepath");
curl 작업의 경우 예를 들어, 수신 포트 9001을 설정할 수 있습니다. io라는 PHP-FPM 프로세스 풀(풀)은 특히 컬 작업(Nginx를 통해 배포됨)을 처리하여 포트 9000에서 수신하는 www 프로세스 풀에 의해 컬 작업이 차단되는 것을 방지합니다.
현재 io 프로세스 풀이 많이 있습니다. 일부 프로세스를 열어도 상관 없습니다:
<code>nginx.conf: 访问io.php的请求都交给监听9001的PHP-FPM进程池处理
location = /io.php {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
php-fpm: 正常脚本由静态www池处理,阻塞脚本由动态io池处理
[www]
;名为www的进程池监听9000端口,常驻进程数量为固定4个
listen = 127.0.0.1:9000
pm = static
pm.max_children = 4
[io]
;名为io的进程池监听9001端口,进程数常驻4个,最大8个
listen = 127.0.0.1:9001
pm = dynamic
pm.max_children = 8
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 4</code>집약적 계산과 I를 분리하기 위해 PHP-FPM에서 제공하는 풀 격리를 사용합니다. /O 집약적인 작업으로 전체 PHP 애플리케이션에 대한 차단의 영향을 줄일 수 있습니다.
빠른 것의 반대말은 안정성입니다.
동시성 등 매우 높은 성능 요구 사항이 없는 일부 웹 사이트의 경우 Apache가 좋은 선택입니다.
두 가지는 초점이 다르기 때문에 Apache 자체에는 많은 기능이 내장되어 있으며 다른 것의 도움 없이 거의 모든 웹 유형 애플리케이션을 지원할 수 있습니다. Nginx는 정적 파일 처리와 높은 동시성 측면에서 장점이 있습니다.
Apache는 완전성과 안정성에 중점을 두고 있다면 Nginx는 경량성과 높은 효율성에 중점을 두고 있습니다. Apache와 Nginx는 Apache 앞에 구성되어 정적 파일(웹 사이트의 리소스)에 대한 요청을 차단하는 데 사용되는 경우가 많습니다. 현재 요청이 대부분을 차지하므로 Nginx가 처리할 수 없는 콘텐츠는 처리를 위해 Apache로 전달됩니다.
nginx는 확실히 더 좋지만 모든 웹사이트가 궁극을 추구하고 그저 혼란스러울 수 있는 것을 사용해야 하는 것은 아닙니다. 결국 사람들은 게으르고 새로운 것을 받아들이는 것을 꺼려하며 위험과 책임을 두려워하기 때문입니다.
LAMP 냄비는 일단 설치하면 사용할 수 있고 훈련 교사가 가르쳐야 합니다. 많은 사람들이 문제에 직면하고 사용법을 아는 것에 적응하기 위해 10배의 작업 시간을 소비합니다. 이 큰 구멍을 채우는 데 100배의 시간을 더 투자한다면 새로운 것을 배우는 데 하루를 보내고 싶지 않을 것입니다.
모든 것에는 장점과 단점이 있으므로 완전히 대체하기는 어려울 것입니다. 게다가, 과거에는 많은 사람들이 새로운 것을 만들기에는 너무 게으른 사람들이었습니다. 처음에는 새로운 것에 대한 거부감이 있어서, 황도에 왔을 때 지하철이 엄청나게 붐비고 속도가 빨랐던 것을 기억합니다. 별로 무섭지 않아요
주로 구성 파일을 변경한 후 적용하려면 Nginx를 다시 시작해야 하기 때문입니다. .htaccess 파일을 직접 구문 분석할 수 있는 Apache와 달리 호스트는 사용자가 자신의 구성 파일을 수정했다고 해서 Nginx를 다시 시작할 수 없습니다. 다른 사용자가 사용합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
