Apache vs Nginx 성능 : 최적화 기술-PHP 튜토리얼-php.cn

Apache vs Nginx Performance: Optimization Techniques 키 포인트

Apache와 Nginx는 모두 강력한 웹 서버이지만 성능은 프로세스 중심의 모델을 채택하는 반면, Nginx는 이벤트 중심의 아키텍처에서 이점이 있습니다. Apache의 주요 최적화에는 Prefork, 작업자 및 연결을보다 효율적으로 처리하기위한 MPMS (Multi-Process Modules)를 튜닝하고 파일 시스템 성능을 오버 헤드를 줄일 수있는 경우 HTACCESS를 비활성화합니다.

NGINX의 경우 주요 성능 향상에는 올바른 작업자 프로세스 및 연결 수 설정, Keepalive 연결을 활용하여 TCP 오버 헤드를 줄이고 컨텐츠를 더 빠르게 제공하기 위해 캐싱 정책을 구현하는 것이 포함됩니다.

웹 서비스 프로세스의 요구에 적응하기 위해 서버 하드웨어 구성 (RAM 추가 및 SSD 사용)을 조정하여 두 서버를 추가로 최적화 할 수 있습니다.

리버스 프록시 설정에서 apache 및 nginx를 사용하면 두 서버를 활용할 수 있으며 Nginx는 정적 컨텐츠 및로드 밸런싱을 처리하는 반면 Apache는 동적 컨텐츠를 처리합니다.

HTOP, 새로운 유물 및 특정 부하 테스트 소프트웨어를 사용한 지속적인 모니터링 및 테스트는 병목 현상을 효과적으로 식별하고 서버 성능을 최적화하는 데 중요합니다.

몇 년 전, Apache Foundation의 웹 서버 ( "Apache"라고 함)는 너무 일반적이어서 "웹 서버"라는 단어와 동의어가되었습니다. Linux 시스템의 데몬은

httpd

( http process 만 의미)로 명명되었으며 기본 Linux 분포에 사전 설치됩니다.

는 원래 1995 년에 출판되었으며 Wikipedia를 "월드 와이드 웹의 초기 개발에서 중요한 역할을 수행했습니다." W3Techs에 따르면 여전히 가장 일반적으로 사용되는 웹 서버 소프트웨어입니다. 그러나 지난 10 년 동안 일부 트렌드를 보여주는 보고서와 다른 솔루션과의 비교를 바탕으로 시장 점유율이 감소하고 있습니다. Netcraft와 Buildwith는 약간 다른 보고서를 제공하지만 Apache의 시장 점유율은 하락 추세에 있으며 Nginx의 시장 점유율이 증가하고 있음에 동의합니다.

2004 년 Igor Sysoev에 의해 nginx (

엔진 x

)가 출시되었으며 Apache를 능가하는 명확한 목표로 출시되었습니다. Nginx의 웹 사이트에는이 두 기술을 비교하는 읽을 가치가있는 기사가 있습니다. 처음에는 주로 정적 파일을 제공하기 위해 Apache에 대한 보완으로 주로 사용되었지만 다양한 웹 서버 작업을 처리하기 위해 계속 발전함에 따라 꾸준히 성장하고 있습니다.

는 일반적으로 리버스 프록시,로드 밸런서 및 HTTP 캐시로 사용됩니다. CDN 및 비디오 스트리밍 제공 업체는이를 사용하여 성능에 중요한 콘텐츠 제공 시스템을 구축합니다.

Apache는 오랫동안 주변에 있었고 선택할 수있는 많은 모듈이 있습니다. Apache 서버 관리는 사용자 친화적 인 것으로 잘 알려져 있습니다. 동적 모듈 로딩을 사용하면 기본 서버 바이너리를 다시 컴파일하지 않고 다른 모듈을 컴파일하고 Apache 스택에 추가 할 수 있습니다. 일반적으로 모듈은 Linux 배포 저장소에 있으며 설치 후 시스템 패키지 관리자를 통해 A2enmod와 같은 명령을 사용하여 스택에 우아하게 추가 할 수 있습니다. Nginx는 아직이 유연성을 보지 못했습니다. HTTP/2를 지원하기 위해 NGINX 설정 안내서를 살펴보면 모듈은 빌드 타임에 구성된 NGINX가 빌드 해야하는 것입니다.

Apache 시장의 지배력에 기여하는 또 다른 기능은 .htaccess 파일입니다. Apache의 킬러이므로 디렉토리 수준에서 서버 구성을 제어 할 수 있으므로 공유 호스팅 환경에 선호되는 솔루션입니다. Apache가 제공하는 서버의 각 디렉토리에는 자체 .htaccess 파일이있을 수 있습니다.

nginx에는 동등한 솔루션이있을뿐만 아니라 성능 영향으로 인해이 사용량을 방지합니다.

1995 년부터 2005 년까지 서버 제조업체 시장 점유율. netcraft 의 데이터 litespeed 또는 LSWS는 성능을 희생하지 않고 유연성 수준이 Apache와 비교할 수있는 서버 경쟁 업체입니다. Apache 스타일 .htaccess, mod_security 및 mod_rewrite를 지원하며 설정을 공유하는 것을 고려할 가치가 있습니다. Apache의 직접적인 교체로 계획되어 있으며 CPANEL 및 PLESK와 함께 사용할 수 있습니다. 2015 년부터 HTTP/2를 지원했습니다.

하드웨어 예방 조치 시스템을 최적화 할 때는 하드웨어 설정에주의를 과도로 강조 할 수 없습니다. 설정을 위해 어떤 솔루션을 선택하든 충분한 RAM을 갖는 것이 중요합니다. 웹 서버 프로세스 나 PHP와 같은 통역사에 RAM이 충분하지 않으면 교환을 시작하고 스왑은 실제로 하드 디스크를 사용하여 RAM 메모리를 보충하는 것을 의미합니다. 이것의 효과는이 메모리에 액세스 할 때마다 대기 시간을 높이는 것입니다. 이것은 우리에게 두 번째 포인트 - 하드 디스크 공간을 상기시킵니다. 빠른 SSD 스토리지를 사용하는 것은 웹 사이트 속도의 또 다른 핵심 요소입니다. 또한 CPU 가용성과 서버 데이터 센터와 대상 고객 간의 물리적 거리에주의를 기울여야합니다. Apache vs Nginx Performance: Optimization Techniques

Apache vs Nginx Performance: Optimization Techniques

성능 튜닝의 하드웨어 측면에 대해 더 깊이 이해하기 위해 Dropbox는 좋은 기사를 가지고 있습니다.

모니터링 현재 서버 스택의 성능을 상세하게 모니터링하는 실질적인 방법은 HTOP이며 Linux, UNIX 및 MACOS에 적합하며 프로세스에 대한 화려한 개요를 제공합니다.

기타 모니터링 도구에는 새로운 Relic (전체 도구 세트가있는 고급 솔루션) 및 NetData (소형 VPS 시스템 및 서버 네트워크 모니터링을위한 우수한 확장 성, 세밀한 메트릭 및 사용자 정의 가능한 웹 대시 보드를 제공하는 오픈 소스 솔루션)가 포함됩니다. 이메일, 슬랙, 푸시 버릿, 전보, 트와 일리오 등을 통해 모든 응용 프로그램 또는 시스템 프로세스에 대한 경고를 보낼 수 있습니다.

monit은 시스템을 모니터링하고 특정 조건이 충족 될 때 우리를 경고하거나 특정 프로세스를 다시 시작하거나 시스템을 다시 시작하도록 구성 할 수있는 또 다른 헤드리스 오픈 소스 도구입니다.
테스트 시스템 AB (Apache Benchmark)는 Apache Foundation의 간단한 부하 테스트 도구이며 Siege는 또 다른 부하 테스트 프로그램입니다. 이 기사에서는이를 설정하는 방법을 설명합니다. 여기에 AB에 대한 고급 팁이 있으며, 포위 공격에 대한 더 깊은 이해는 여기에서 찾을 수 있습니다.
웹 인터페이스를 선호하는 경우 Locust는 웹 사이트 성능을 테스트하기에 매우 편리한 파이썬 기반 도구입니다.

메뚜기를 설치 한 후, 우리는 그것을 시작할 디렉토리에서 메뚜기 파일을 만들어야합니다.
그런 다음 명령 줄에서 시작합니다.
이러한 부하 테스트 도구에 대한 경고 : DDOS 공격의 영향을 미치므로 테스트를 자신의 웹 사이트로 제한하는 것이 좋습니다.
조정 apache Apache의 MPM 모듈 Apache는 1995 년과 인터넷 초반으로 거슬러 올라갑니다. 서버를 실행할 수있는 허용 가능한 방법은 수신 한 TCP 연결에 새로운 프로세스를 생성하고 이에 대한 답장을하는 것이 었습니다. 더 많은 연결이 들어 오면 더 많은 작업자 프로세스가이를 처리하도록 만들어집니다. 새로운 프로세스를 생성하는 비용은 매우 높으며 Apache 개발자는 특정 수의 프로세스를 사전 제작하는
prefork
모드를 설계했습니다. 각 프로세스에 포함 된 동적 언어 통역사 (예 : Mod_php)는 여전히 비싸고 Apache의 기본 설정으로 인해 서버가 충돌합니다. 각 프로세스는 하나의 들어오는 연결 만 처리 할 수 있습니다.
이 모델은 Apache의 MPM (Multi-Process Module) 시스템에서 라고합니다. Apache의 웹 사이트에 따르면,이 모드는 자체 조절할 수있는 구성이 거의 필요하지 않으며, 가장 중요한 것은 MaxRequestWorkers 지시문이 예상만큼 많은 동시 요청을 처리 할 수있을 정도로 크지 만 확인하기에 충분히 작습니다. 모든 프로세스에는 충분한 물리적 RAM이 있습니다.

수신 트래픽을 처리하기 위해 생성 된 많은 수의 아파치 프로세스를 보여주는 작은 메뚜기 하중 테스트. 우리는이 패턴이 Apache의 악명 높은 명성의 주된 이유 일 수 있다고 덧붙일 수 있습니다. 리소스 비효율적 일 수 있습니다. Apache의 버전 2.0은 prefork 모드 문제를 해결하려는 두 개의 다른 MPM을 가져옵니다. 그들은 작업자 모듈 또는
mpm_worker_module 및 이벤트 모듈 입니다.

작업자 모듈은 더 이상 프로세스 기반이 아닙니다. Apache의 웹 사이트를 견적하십시오 : 단일 제어 프로세스 (부모 프로세스)는 아동 프로세스를 시작할 책임이 있습니다. 각 어린이 프로세스는 ThreadSperchild 지시문에 지정된 숫자를 기반으로 고정 된 수의 서버 스레드와 연결을 청취하고 연결이 도착했을 때 처리를 위해 서버 스레드로 전달하는 청취 스레드를 생성합니다. 이 모드는 더 많은 리소스를 절약합니다. Apache의 버전 2.4는 세 번째 MPM- 이벤트 모듈을 제공합니다. 작업자 MPM을 기반으로하며 HTTP 요청이 완료된 후 졸린 keepalive 연결을 관리하는 별도의 청취 스레드를 추가합니다. 메모리 풋 프린트가 작은 비 블로킹 비동기 모드입니다. 버전 2.4에 대한 자세한 내용은 여기에 있습니다. 우리는 Virtual Server에 약 1200 개의 게시물이있는 Test WooCommerce 설치 프로그램을로드하고 Default Prefork 모드 및 Mod_php로 Apache 2.4에서 테스트했습니다. 먼저, 우리는 https://tools.pingdom.com에서 libapache2-mod-php7 및 mmpm_prefork_module을 사용하여 테스트했습니다. 그런 다음 이벤트 MPM 모듈을 테스트했습니다.

우리는 /etc/apt/sources.list에 multiverse를 추가해야합니다

그런 다음 Sudo Apt-Get 업데이트를 실행하고 libapache2-mod-fastcgi 및 php-fpm을 설치합니다.

PHP-FPM은 Apache와는 별도의 서비스이므로 다시 시작해야합니다.

그런 다음 Prefork 모듈을 비활성화하고 활성화 이벤트 모드 및 proxy_fcgi : 를 비활성화했습니다.
우리는이 스 니펫을 Apache 가상 호스트에 추가합니다.
이 포트는 /etc/php/7.0/fpm/pool.d/www.conf의 php-fpm 구성과 일치해야합니다. PHP-FPM 설정에 대한 자세한 내용은 다음과 같습니다.

그런 다음 그런 다음 /etc/apache2/mods-available/mpm_event.conf에서 mpm_event configuration을 조정했습니다. Apache 웹 사이트의 각 지침에 대한 자세한 내용과 이벤트 MPM에 대한 팁은 여기를 참조하십시오. 시작 서버

는 아무리 바쁘더라도 일정량의 메모리를 소비 할 것임을 기억하십시오. MaxRequestWorkers 지시문은 허용되는 동시 요청 수를 설정합니다. MaxConnectionsPerchild를 0이 아닌 값으로 설정하는 것은 메모리 누출이 발생하지 않기 때문에 중요합니다.

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

로그인 후 복사

그런 다음 Sudo Service Apache2 재시작을 사용하여 서버를 다시 시작합니다 (ThreadLimit과 같은 일부 지침을 변경하는 경우 Sudo Service Apache2 STOP; Sudo Service Apache2 시작을 사용하여 명시 적으로 중지하고 서비스를 시작해야합니다).

Pingdom에 대한 우리의 테스트는 이제 페이지 로딩 시간이 절반 이상 줄어드는 것을 보여줍니다.

Apache 조정을위한 기타 팁 : disable.htaccess : htaccess를 사용하면 다시 시작하지 않고 서버 루트 디렉토리의 각 디렉토리에 대한 특정 구성을 설정할 수 있습니다. 따라서 각 요청에서 .htaccess 파일을 찾기 위해 모든 디렉토리를 반복하면 성능 손실이 발생합니다.

Apache 문서에서 인용 :

일반적으로, .htaccess 파일은 기본 서버 구성 파일에 액세스 할 수있는 권한이없는 경우에만 사용해야합니다. … 일반적으로 .htaccess 파일은 가능한 한 많이 피해야합니다. 메인 서버 구성 파일에서 Apache vs Nginx Performance: Optimization Techniques 섹션을 사용하는 것만 큼 효율적으로 .htaccess 파일에 넣을 것으로 생각되는 구성을 수행 할 수 있습니다.

솔루션은 /etc/apache2/apache2.conf : 에서 비활성화하는 것입니다

특정 디렉토리에 필요한 경우 가상 호스트 파일의

섹션에서 활성화 할 수 있습니다.

<:> 다른 팁에는 다음이 포함됩니다

만료 헤더를 설정하여 브라우저 캐시를 제어하기 위해 mod_expires를 사용하십시오.

hostnamelookups를 계속 유지하십시오 - hostnamelookups는 Apache 1.3 이후 기본값이되었지만 성능 손실이 발생할 수 있으므로 남아 있는지 확인하십시오.
Apache2buddy는 시스템을 조정하기 위해 트릭을 얻을 수있는 간단한 스크립트입니다. https://www.php.cn/link/5b3a93d103a6345e5d404c61c5b5081 |

nginx

nginx는 이벤트 중심 및 비 블로킹 웹 서버입니다. 해커 뉴스에 포스터를 인용하십시오

포킹 프로세스는 이벤트 루프에 비해 매우 비쌉니다. 이벤트 기반 HTTP 서버가 궁극적으로 승리합니다.

<code>locust --host=https://my-website.com
</code>

로그인 후 복사

이 진술은 해커 뉴스에 대한 다소 격렬한 논쟁을 불러 일으켰지 만, 우리의 경험에서 MPM_PREFORK APACHE에서 NGINX로 전환하면 일반적으로 웹 사이트가 충돌하는 것을 방지하는 것을 의미합니다. 단순히 Nginx로 전환하는 것은 일반적으로 그 자체로 해결 방법입니다. Nginx 아키텍처에 대한보다 포괄적 인 시각적 설명은 여기에서 찾을 수 있습니다. nginx 설정 nginx는 Worker_Processes를 /etc/nginx/nginx.conf에서 자동으로 설정하여 (Apache의 MPM_Event 구성과 마찬가지로) 작업자 수를 PC 코어 수로 고정하는 것이 좋습니다 (기본값은 1).

worker_connections 각 작업자 프로세스가 처리 할 수있는 연결 수를 설정합니다. 기본값은 512이지만 일반적으로 증가 할 수 있습니다.

Keepalive 연결은 성능에 영향을 미치는 서버 측면이며, 일반적으로 벤치 마크에서는 보이지 않습니다.

nginx 웹 사이트에 따르면

HTTP KeepAlive 연결은 대기 시간을 줄이고 웹 페이지로드를 속도를 높이는 필수 성능 기능입니다. Apache vs Nginx Performance: Optimization Techniques

새로운 TCP 연결을 설정하는 것은 비용이 많이들 수 있습니다.

https

암호화와 관련된 상황은 말할 것도 없습니다. HTTP/2 프로토콜은 이것을 다중화 기능으로 완화합니다. 기존 연결을 재사용하면 요청 시간을 줄일 수 있습니다.

Apache의 MPM_PREFORK 및 MPM_WORKER는 동시성 제한 사항을 가지고 있으며 이는 KeepAlive 이벤트 루프와 대조적입니다. 이것은 Apache 2.4의 MPM_EVENT 모듈에서 어느 정도 고정되어 있으며 Nginx에서 유일한 기본 작동 모드로 나타납니다. NGINX Worker는 동시에 수천 개의 들어오는 연결을 처리 할 수 있으며 역전 프록시 또는로드 밸런서로 사용되면 NGINX는 TCP 연결 오버 헤드가없는 로컬 KeepAlive 연결 풀을 사용합니다.
<_> keporalive_requests는 클라이언트가 단일 requalive 연결을 통해 할 수있는 요청 수를 조절하는 설정입니다. KeepAlive_timeout은 유휴 상태 연결이 열려있는 시간을 설정합니다.
KeepAlive는 프록시 또는로드 밸런서 역할을 할 때 Nginx의 업스트림 서버와의 연결과 관련된 설정입니다. 이는 작업자 프로세스 당 무료 유지 업 스트림 연결의 수를 의미합니다.

업스트림 keepalive 연결을 활성화하려면 이러한 지침을 Nginx 기본 구성에 넣어야합니다.

nginx 업스트림 연결은 NGX_HTTP_UPSTREAM_MODULE에 의해 관리됩니다. 프론트 엔드 애플리케이션이 업데이트에 대한 백엔드 애플리케이션을 계속 설문 조사에 참여하면 recopalive_requests를 증가시키고 cheepalive_timeout을 늘리면 필요한 연결 수가 제한됩니다. KeepAlive 지시문은 업스트림 서버에 다른 연결을 허용하기에는 너무 크지 않아야합니다. 이러한 설정에 대한 조정은 특정 상황을 기반으로하며 테스트해야합니다. 이것은 아마도 KeepAlive에 기본 설정이없는 이유 중 하나 일 것입니다.

Unix 소켓을 사용하는 기본적으로 Nginx는 별도의 PHP 프로세스를 사용하여 PHP 파일 요청을 전달합니다. 여기에서는 프록시 역할을합니다 (PHP7.0-FPM으로 Apache를 설정할 때와 마찬가지로).

일반적으로 nginx를 사용하는 가상 호스트 설정은 다음과 같습니다.

FASTCGI 및 HTTP는 다른 프로토콜이므로 처음 두 줄은 일부 매개 변수와 헤더를 PHP -FPM으로 전달하는 반면, 세 번째 줄은 로컬 네트워크 소켓을 통해 프록시 요청 방법을 지정합니다.

이것은 요청을 프록시 할 원격 서버를 지정할 수도 있기 때문에 멀티 서버 설정에 실용적입니다.

그러나 단일 시스템에서 전체 설정을 호스팅하는 경우 UNIX 소켓을 사용하여 청취 PHP 프로세스에 연결해야합니다.

UNIX 소켓은 TCP보다 성능이 향상되는 것으로 간주 되며이 설정은 더 안전한 것으로 간주됩니다. 이 기사에서 랙 스페이스 의이 설정에 대한 자세한 내용은 찾을 수 있습니다.

UNIX 소켓에 대한이 팁은 Apache에도 적용됩니다. 자세한 내용은 여기에 있습니다.

<_> gzip_static : 웹 서버 성능에 대한 일반적인보기는 정적 자원을 압축하는 것입니다. 이는 일반적으로 각 요청의 동적 압축 자원이 비쌀 수 있으므로 특정 임계 값을 초과하는 파일 만 타협하고 압축하려고 시도한다는 것을 의미합니다. Nginx는 일반 리소스 대신 GZIP 버전의 파일 (Extension .gz)을 제공 할 수있는 gzip_static 지시문이 있습니다.

이 방법으로, nginx는 style.css 대신 Style.css.gz를 제공하려고 노력할 것입니다 (이 경우 우리는 스스로 gzipping을 처리해야합니다).

이러한 방식으로 CPU 사이클은 각 요청에 대해 동적 압축에 낭비되지 않습니다.

nginx <code>from locust import HttpLocust, TaskSet, task class UserBehavior(TaskSet): @task(1) def index(self): self.client.get("/") @task(2) def shop(self): self.client.get("/?page_id=5") @task(3) def page(self): self.client.get("/?page_id=2") class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 300 max_wait = 3000 </code>가있는 캐시 Nginx에 대한 이야기는 콘텐츠를 캐시하는 방법을 언급하지 않고 불완전합니다. NGINX 캐싱은 너무 효율적이므로 많은 시스템 관리자가 별도의 HTTP 캐시 레이어 (예 : 바니시)가 그다지 의미가 없다고 생각합니다. "단순성은 특징입니다." Nginx 캐싱을 활성화하는 것은 매우 간단합니다.

이것은 서버 블록 외부에있는 가상 호스트 파일에 우리가 배치하는 지침입니다. proxy_cache_path 매개 변수는 캐시를 저장하려는 모든 경로가 될 수 있습니다. 레벨은 Nginx가 캐시 된 컨텐츠를 저장 해야하는 디렉토리 수준의 수를 지정합니다. 성능의 이유로 두 레벨은 일반적으로 괜찮습니다. 디렉토리를 가로 지르는 데 시간이 많이 걸릴 수 있습니다. Keys_Zone 매개 변수는 캐시 키를 저장하는 데 사용되는 공유 메모리 영역의 이름이며 10m은 메모리의 이러한 키를위한 공간입니다 (10MB는 일반적으로 충분합니다. 이것은 실제 캐시 된 컨텐츠의 공간이 아닙니다). Max_Size는 선택 사항이며 캐시 된 내용의 상한을 설정합니다. 여기 10GB가 있습니다. 지정되지 않으면 사용 가능한 모든 공간을 차지합니다. 비활성은 컨텐츠가 캐시에 머무를 수있는 시간을 요청한 다음 Nginx에 의해 삭제됩니다.

설정 후 메모리 영역의 이름을 포함하는 다음 줄을 서버 또는 위치 블록에 추가합니다.

서버 또는 위치 블록 지침에 대한 자세한 내용은 Nginx 캐시를 추가로 조정하려면 여기를 참조하십시오.

지시문은 정적 자원에 사용되지만 일반적으로 웹 응용 프로그램의 동적 출력을 캐시하거나 CMS 또는 다른 것인지에 관계없이 캐시를 원합니다. 이 경우, 우리는 proxy 대신 cache

<code>locust --host=https://my-website.com
</code>

로그인 후 복사

위의 마지막 줄은 응답 헤더를 설정하여 콘텐츠가 캐시에서 전달되는지 여부를 알려줍니다.

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

로그인 후 복사

FastCGI_CACHE* 라인 및 FASTCGI_NO_CACHE는 캐싱 및 제외를 규제합니다. 이 모든 지침에 대한 자세한 참조는 Nginx 문서 웹 사이트에서 찾을 수 있습니다.

더 많은 것을 배우기 위해 Nginx 직원은이 주제에 대한 무료 웹 세미나를 제공했으며 많은 전자 책이 있습니다.

결론 우리는 웹 서버 성능과 그 뒤에있는 이론을 개선하는 데 도움이되는 일부 기술을 소개하려고 노력합니다. 그러나이 주제는 결코 철저하지 않습니다. 우리는 여전히 역 프록시 설정 또는 Apache 및 Nginx로 구성된 멀티 서버 설정을 다루지 않습니다. 두 서버의 최상의 결과는 특정 실제 사례 테스트 및 분석에 따라 다릅니다. 이것은 끝없는 주제입니다.

Apache 및 Nginx 성능 최적화 기술에 대한 FAQ 성능과 최적화 측면에서 Apache와 Nginx의 주요 차이점은 무엇입니까?

Apache와 Nginx는 모두 강력한 웹 서버이지만 성능 및 최적화 기능에는 상당한 차이가 있습니다. Apache는 프로세스 중심 모델을 사용하여 각 요청마다 새 스레드를 생성하는 이전 서버입니다. 이로 인해 여러 동시 연결을 다룰 때 많은 양의 메모리 사용이 발생할 수 있습니다. 반면에 Nginx는 메모리 사용량이 거의없이 수천 개의 연결을 동시에 처리 할 수있는 이벤트 중심 아키텍처를 사용합니다. 이로 인해 특히 정적 컨텐츠 전달 및 리버스 프록시 시나리오에서 NGINX가보다 효율적이고 빠릅니다.

더 나은 성능을 위해 nginx를 최적화하는 방법은 무엇입니까?

더 나은 성능을 위해 Nginx를 최적화하는 여러 가지 방법이 있습니다. 먼저 작업자 프로세스 및 작업자 연결을 조정할 수 있습니다. 작업자 프로세스는 CPU 또는 코어 수로 설정되어야하며 작업자 연결은 최대 개방 파일 제한으로 설정해야합니다. 둘째, GZIP 압축을 활성화하여 NGINX가 클라이언트로 보내는 데이터의 크기를 줄일 수 있습니다. 셋째, 캐시를 사용하여 자주 액세스하는 데이터를 메모리에 저장하여 디스크 I/O 작동을 줄일 수 있습니다. 마지막으로로드 밸런싱을 사용하여 여러 서버에 네트워크 트래픽을 확산시켜 응답 시간과 전반적인 성능을 향상시킬 수 있습니다.

더 나은 성능을 위해 Apache를 최적화하는 방법은 무엇입니까?

아파치는 다양한 방식으로 최적화 될 수 있습니다. 먼저 최대 동시 연결 수를 제어하기 위해 MaxClients 지시문을 조정할 수 있습니다. 둘째, mod_deflate가 클라이언트로 보내기 전에 데이터를 압축 할 수 있도록하여 대역폭 사용이 줄어 듭니다. 셋째, 캐시에 mod_cache를 사용하여 자주 액세스하는 데이터를 메모리에 저장하여 디스크 I/O 작동을 줄일 수 있습니다. 마지막으로 Mod_proxy_Balancer를 사용하여 밸런싱을로드하여 여러 서버에 네트워크 트래픽을 전파하여 응답 시간과 전반적인 성능을 향상시킬 수 있습니다.

Apache와 Nginx를 동시에 사용할 수 있습니까?

예, 리버스 프록시 설정에서 apache와 nginx를 모두 사용할 수 있습니다. 이 구성에서 Nginx는 클라이언트 요청을 처리하는 프론트 엔드 서버 역할을하며 Apache는 이러한 요청을 처리하는 백엔드 서버 역할을합니다. 이 설정은 두 서버의 장점을 결합하여 Nginx는 정적 컨텐츠를 효율적으로 처리하는 반면 Apache는 동적 컨텐츠 처리를 제공합니다.

Nginx는 다양한 방식으로 정적 및 동적 컨텐츠를 어떻게 처리합니까?