Apache 대 NGINX - 성능 면에서 누가 이기나요?

Apache 대 NGINX는 (NGINX 출시 이후) 가장 뜨거운 논쟁 중 하나입니다. 둘 다 LiteSpeed ​​및 OpenLiteSpeed에 이어 가장 일반적인 웹 서버 중 하나이기 때문입니다.

Apache와 NGINX는 전 세계 웹사이트의 거의 60%를 차지합니다. Apache와 NGINX는 성능 및 기능 면에서 유사합니다. 반면 아키텍처, 보안 및 성능은 모두 다릅니다.

이 두 서버는 모두 우수하기 때문에 선택하기 어려울 수 있습니다. 각 웹 서버에는 고유한 장점과 단점이 있기 때문에 가능한 최상의 옵션을 만드는 것이 중요합니다.

여기에서 openlitespeed 대 nginx 토론을 확인할 수도 있습니다.

Apache 대 NGINX 속도 비교

Apache 대 NGINX 논쟁에 대해 자세히 알아보기 전에. 먼저 간단한 속도 테스트를 수행하고 다음 시나리오에서 테스트를 수행합니다.

• 5KB의 작은 정적 파일을 테스트해 보겠습니다.
• 1MB 크기의 정적 파일
• 간단한 PHP Hello World 애플리케이션 테스트
• WordPress용 Apache 및 NGINX 벤치마킹

우리는 openlitespeed 대 nginx를 테스트하기 위해 동일한 절차를 사용했습니다. OpenLiteSpeed는 기본 .htaccess 재작성 규칙도 지원하므로 NGINX에 대한 정말 훌륭한 대안이므로 Apache에서 OpenLiteSpeed로 쉽게 이동할 수 있습니다.

5KB의 작은 정적 파일을 테스트해 보겠습니다.

최종 평결 : 두 서버 모두 작은 정적 파일로 동일하게 수행되었습니다.

아파치

NGINX

1MB 크기의 정적 파일

최종 평결 : NGINX는 대용량 정적 파일로 분명히 승리했습니다.

아파치

NGINX

간단한 PHP Hello World 애플리케이션 테스트

최종 평결 : 두 서버 모두 hello world php 애플리케이션과 동일하게 수행되었습니다.

아파치

NGINX

WordPress용 Apache 및 NGINX 벤치마킹

최종 평결 : NGINX는 WordPress 사이트에서 분명히 승리했습니다. 이 가이드를 사용하여 WooCommerce Store 속도를 높일 수 있습니다.

아파치

NGINX

테스트 결과 - Apache 대 NGINX

테스트에서 알 수 있듯이 NGINX는 속도 면에서 Apache보다 상대적으로 우수합니다. 결과는 다음과 같습니다.

1. 5KB의 작은 정적 파일을 테스트합니다.

이 테스트에서 우리는 두 Apache 광고 NGINX가 상대적으로 동일한 결과를 제공한다는 것을 알 수 있습니다.

2. 1MB 크기의 대용량 정적 파일 테스트:

이 테스트에서 우리는 NGINX의 속도가 Apache보다 훨씬 뛰어남을 알 수 있습니다. NGINX는 평균 응답 시간이 훨씬 짧습니다.

3. 간단한 PHP Hello World 애플리케이션 테스트

이 테스트에서 Apache와 NGINX 모두 상대적으로 동일한 결과를 제공하고 있음을 알 수 있습니다.

4. Apache 및 WordPress용 NGINX 테스트

이 테스트에서 우리는 NGINX의 평균 응답 시간이 Apache보다 훨씬 짧고 NGINX보다 더 빠른 속도를 제공한다는 것을 알 수 있습니다.

아파치

Apache를 오픈 소스 웹 서버로 유지 관리하는 개발자 커뮤니티가 있습니다. 각 연결 요청에 대해 새 스레드를 생성하는 프로세스 중심 아키텍처를 사용합니다.
또한 Apache는 웹 서버의 기능을 향상시키는 데 사용할 수 있는 다양한 모듈을 제공합니다. Apache는 확장 및 모듈을 사용하여 다양한 환경의 요구 사항을 충족할 수 있도록 빠르고 안정적이며 안전하며 고도로 사용자 정의할 수 있습니다.

연결 처리 아키텍처

Apache에는 클라이언트 요청이 처리되는 방식을 제어하는 ​​여러 다중 처리 모듈(Apache에서 MPM이라고 함)이 있습니다. 기본적으로 이를 통해 관리자는 연결 처리 아키텍처를 신속하게 전환할 수 있습니다.

• mpm-Prefor: 이 MPM(Multi-Processing Module)은 스레드되지 않은 사전 분기 웹 서버를 구현합니다. 각 서버 프로세스는 들어오는 요청에 응답할 수 있으며 서버 풀의 크기는 상위 프로세스에서 관리합니다. 스레드로부터 안전하지 않은 라이브러리로 작업하기 위해 스레딩을 피해야 하는 사이트에 적합합니다. 또한 각 요청을 격리하여 하나의 문제가 다른 요청에 영향을 미치지 않도록 하는 최고의 MPM입니다.
• mpm-worker: 하이브리드 다중 프로세스 다중 스레드 서버는 이 MPM(Multi-Processing Module)에 의해 구현됩니다. 스레드를 사용하여 요청을 전달하기 때문에 프로세스 기반 서버보다 적은 시스템 리소스로 많은 요청을 처리할 수 있습니다. 각각 많은 스레드가 있는 수많은 프로세스를 사용 가능하게 유지함으로써 프로세스 기반 서버의 안정성을 상당 부분 유지합니다.
• mpm-event: MPM(Multi-Processing Module) 이벤트는 특정 처리를 리스너 스레드에 위임하고 작업자 스레드가 새 요청을 처리할 수 있도록 하여 여러 요청을 동시에 처리할 수 있도록 합니다.
  Apache는 다양한 연결 및 요청 처리 알고리즘 중에서 선택할 수 있는 유연한 설계를 제공합니다. 인터넷 환경이 변화함에 따라 제시된 선택 사항은 주로 서버의 진화와 동시성에 대한 수요 증가의 산물입니다.

정적 콘텐츠와 동적 콘텐츠

정적 콘텐츠는 표준 파일 기반 메커니즘을 사용하여 Apache 서버에서 처리할 수 있습니다. 위에서 언급한 MPM 접근 방식은 대부분 이러한 절차의 수행을 담당합니다.

Apache는 각 작업자 인스턴스에 언어별 프로세서를 포함하여 동적 콘텐츠를 추가로 처리할 수 있습니다. 이를 통해 웹 서버 내에서 외부 구성 요소를 사용하지 않고 동적 콘텐츠를 실행할 수 있습니다. 동적으로 로드 가능한 모듈을 사용하여 이러한 동적 프로세서를 활성화할 수 있습니다.

Apache는 내부적으로 동적 콘텐츠를 처리할 수 있기 때문에 일반적으로 동적 처리 구성이 더 쉽습니다. 컨텐츠 요구 사항이 변경되면 모듈을 쉽게 교체할 수 있으며 추가 소프트웨어와 통신을 조정할 필요가 없습니다.

분산 구성과 중앙 집중식 구성

컨텐츠 폴더 자체 내 숨겨진 파일의 지시문을 분석하고 해석함으로써 Apache는 디렉토리별로 추가 구성을 허용하는 옵션을 추가합니다. .htaccess 파일은 이러한 파일의 이름입니다.

이러한 파일은 콘텐츠 폴더 내에 있기 때문에 Apache는 요청된 파일에 대한 경로의 각 구성 요소에서 .htaccess 파일을 찾고 거기에 있는 지시문을 적용합니다. 이는 URL 재작성, 액세스 제한, 권한 부여 및 인증, 심지어 캐시 정책에 일반적으로 사용되는 분산 웹 서버 설정을 효과적으로 가능하게 합니다.

앞의 모든 예는 기본 Apache 구성 파일에서 설정할 수 있지만 .htaccess 파일은 많은 이점을 제공합니다. 첫째, 요청 경로를 따라 만날 때마다 평가되기 때문에 서버를 다시 로드할 필요 없이 구현됩니다. 둘째, 권한이 없는 사용자가 구성 파일에 대한 완전한 권한을 부여하지 않고도 자신의 웹 콘텐츠의 특정 부분을 제어할 수 있습니다.

콘텐츠 관리 시스템과 같은 특정 웹 소프트웨어는 이제 중앙 구성 파일에 액세스하지 않고도 환경을 쉽게 사용자 지정할 수 있습니다. 공유 호스팅 공급자는 이를 활용하여 클라이언트에게 특정 디렉토리에 대한 액세스를 제공하면서 핵심 설정을 계속 제어할 수 있습니다.

파일 대 URI 기반 해석

Apache는 요청을 보다 추상적인 평가가 필요한 물리적 파일 시스템 리소스 또는 URI 대상으로 해석할 수 있습니다. 일반적으로 Apache는 전자에 대해 <Directory> 또는 <File> 블록을 사용하는 반면, 보다 추상적인 리소스에는 <Location> 블록을 사용합니다.

Apache는 처음부터 웹 서버로 구축되었기 때문에 기본적으로 요청을 파일 시스템 리소스로 해석합니다. 실제 파일을 찾으려면 문서 루트로 시작하여 호스트 및 포트 번호 다음에 요청 부분을 추가합니다. 웹에서 파일 시스템 계층은 기본적으로 사용 가능한 문서 트리로 표시됩니다.

요청이 기본 파일 시스템과 일치하지 않는 경우 Apache는 여러 옵션을 제공합니다. 예를 들어 Alias ​​지시문을 사용하여 다른 위치에 매핑할 수 있습니다. 파일 시스템 대신 <Location> 블록을 사용하면 URI로 직접 작업할 수 있습니다. 파일 시스템 전체에 구성을 보다 유연하게 적용하기 위해 정규식 변형도 사용할 수 있습니다.

Apache는 기본 파일 시스템과 웹 공간 모두에서 작동할 수 있지만 파일 시스템 기술을 사용하는 것을 선호합니다. 디렉토리별 설정을 위한 .htaccess 파일 사용과 같은 일부 설계 결정은 이를 반영합니다.

계수

Apache의 모듈 시스템을 사용하면 서버가 실행되는 동안 필요에 따라 모듈을 동적으로 로드 및 언로드할 수 있습니다. Apache 코어는 항상 존재하지만 모듈을 활성화 또는 비활성화하여 기능을 추가 또는 삭제하고 주 서버에 연결할 수 있습니다.

이 기능은 Apache에서 광범위한 작업에 사용됩니다. 플랫폼의 성숙도 때문에 대규모 모듈 라이브러리가 함께 제공됩니다. 예를 들어 Mod php는 실행 중인 각 작업자에 PHP 인터프리터를 포함하고 서버의 필수 기능 일부를 변경하는 데 사용할 수 있습니다.

반면에 모듈은 동적 콘텐츠만 처리하는 것이 아닙니다. URL 재작성, 클라이언트 인증, 서버 강화, 로그, 캐시, 압축, 프록시, 속도 제한, 데이터 암호화 등의 기능을 수행할 수 있습니다. 많은 작업을 추가하지 않고도 향상된 기능을 제공할 수 있습니다.

지원, 호환성, 생태계 및 문서

Apache는 오랫동안 사용되어 왔기 때문에 많은 지원이 있습니다. Apache를 다른 소프트웨어에 연결하는 것과 관련된 코어 서버 및 작업 기반 상황의 경우 액세스할 수 있는 상당한 양의 자사 및 타사 설명서 라이브러리가 있습니다.

많은 도구와 웹 프로젝트에는 문서 외에도 Apache 환경 내에서 자체적으로 부트스트랩하는 도구가 포함되어 있습니다. 이것은 프로젝트 자체에서 또는 배포판의 패키징 팀이 유지 관리하는 패키지에서 제공될 수 있습니다.

시장 점유율과 사용 가능한 시간 때문에; Apache는 일반적으로 타사 프로젝트에서 더 많은 지원을 받게 됩니다. 관리자는 Apache의 광범위한 사용뿐만 아니라 많은 사람들이 .htaccess 분산 관리 기능으로 인해 Apache가 거의 단독으로 사용되는 공유 호스팅 환경에서 경력을 시작하기 때문에 Apache와 함께 작업했을 가능성이 더 큽니다.

Apache와 NGINX의 장점

많은 웹마스터와 개발자는 NGINX보다 Apache가 훨씬 오래되었기 때문에 Apache를 선호합니다. Windows, Unix 및 Linux 운영 체제와 호환됩니다.

• 다이나믹한 소재를 서빙하는 데 탁월한 성능을 발휘합니다.
• 모듈을 동적으로 로드 및 언로드합니다.
• 시스템 전체 설정을 무효화하는 데 사용할 수 있는 디렉토리별 .htaccess 파일을 제공합니다.
• 지원 및 문서가 탁월합니다.
• 이 모델은 프로세스당 하나의 연결 방식을 사용합니다.
• 여기에는 추가 보안 계층을 추가하는 mod_evasive 및 mod_security 모듈이 포함됩니다.

Apache 대 NGINX의 단점

• 동시에 많은 수의 요청을 처리할 수 없습니다.
• NGINX에 비해 정적 콘텐츠를 표시하는 데 시간이 더 오래 걸립니다.
• 광범위한 설정 및 관리 기능을 제공합니다. 결과적으로 초보자에게는 적합하지 않습니다.
• 트래픽이 많은 웹 사이트에는 성능 문제가 있습니다.

NGINX

"C10k" 문제를 극복하기 위해 러시아 코더 Igor Sysoev가 NGINX를 발명했습니다. Igor는 목표를 달성했습니다. NGINX는 10,000개 이상의 동시 연결을 쉽게 관리할 수 있습니다. 새로운 연결을 더 잘 처리하기 위해 NGINX는 이벤트 기반 및 비동기식 설계를 가지고 있습니다. NGINX는 많은 기능을 제공하는 웹 서버입니다. 다음은 그 중 몇 가지입니다.

• HTTP 캐시 및 로드 밸런서
• Apache 및 기타 웹 서버의 프런트 엔드 프록시.
• HTTP, HTTPS, SMTP, POP3 및 IMAP 프로토콜은 모두 이 역방향 프록시 서버에서 제공됩니다.

NGINX는 출시 이후 리소스 사용량이 적고 저렴한 하드웨어에서 효과적으로 확장할 수 있어 인기가 높아졌습니다. NGINX는 정적 자료를 신속하게 제공하는 것을 전문으로 하는 웹 서버이며 이러한 작업에 더 적합한 소프트웨어에 동적 요청을 전달하도록 설계되었습니다.

연결 처리 아키텍처

NGINX는 대규모 사이트에서 직면하게 될 동시성 문제에 대한 더 나은 이해와 함께 Apache 이후에 등장했습니다. NGINX는 이 정보를 활용하기 위해 비동기, 비차단, 이벤트 기반 연결 처리 알고리즘을 사용하여 처음부터 구축되었습니다.

NGINX는 각각 수만 개의 연결을 처리할 수 있는 작업자 프로세스를 생성합니다. 작업자 프로세스는 정기적으로 이벤트를 확인하고 처리하는 빠른 반복 메커니즘을 개발하여 이를 달성합니다. 연결에서 실제 작업을 분리하여 각 작업자는 새 이벤트가 발생한 경우에만 연결에 집중할 수 있습니다.

작업자의 각 연결은 다른 연결과 공존하는 이벤트 루프에 배치됩니다. 이벤트는 루프 내에서 비동기식으로 처리되므로 비차단 방식으로 작업을 수행할 수 있습니다. 링크는 루프가 닫힌 후 루프에서 삭제됩니다.

NGINX는 연결 처리 방식 덕분에 최소한의 리소스로 매우 멀리 확장할 ​​수 있습니다. 서버가 단일 스레드이고 각각의 새 연결을 처리하기 위해 추가 프로세스가 생성되지 않기 때문에 서버에 과도한 압력이 가해지는 경우에도 메모리 및 CPU 사용이 비교적 일정하게 유지됩니다.

정적 콘텐츠와 동적 콘텐츠

NGINX에는 동적 콘텐츠 처리에 대한 기본 지원이 없습니다. NGINX는 처리를 위해 PHP 및 기타 동적 콘텐츠 요청을 외부 프로세서에 전달한 다음 렌더링된 콘텐츠가 반환될 때까지 기다려야 합니다. 그러면 클라이언트에게 결과를 알릴 수 있습니다.

관리자의 경우 이는 NGINX가 이해하는 프로토콜(http, FastCGI, SCGI, uWSGI, memcache) 중 하나를 사용하여 NGINX와 프로세서 간의 통신을 구성해야 함을 의미합니다. 이것은 프로세서에 대한 각 호출에 새로운 연결이 필요하기 때문에 특히 허용할 연결 수를 추정할 때 상황을 조금 더 복잡하게 만들 수 있습니다.

반면에 이 전략은 몇 가지 이점을 제공합니다. 동적 인터프리터의 오버헤드는 작업자 프로세스에 포함되지 않기 때문에 동적 자료에 대해서만 존재합니다. 정적 콘텐츠는 필요한 경우에만 인터프리터와 상의하여 간단한 방식으로 보낼 수 있습니다. 이것은 Apache에서도 가능하지만 이전 섹션에서 언급한 이점을 제거합니다.

분산 구성과 중앙 집중식 구성

NGINX는 .htaccess 파일을 이해하지 못하며 기본 구성 파일 외부에서 디렉토리별 구성을 평가할 방법이 없습니다. Apache 접근 방식보다 덜 다재다능하지만 고유한 이점이 있습니다.

향상된 성능은 디렉터리 수준 설정의 .htaccess 접근 방식에 비해 가장 눈에 띄는 이점입니다. 각 요청에 대해 서버는 모든 디렉토리에서 .htaccess 를 허용하는 표준 Apache 설정에서 요청된 파일까지 이어지는 각 상위 디렉토리에서 이러한 파일을 확인합니다. 이 검색에서 하나 이상의 .htaccess 파일이 나타나면 해당 파일을 읽고 처리해야 합니다. NGINX는 디렉토리 재정의를 허용하지 않음으로써 각 요청에 대해 단일 디렉토리 쿼리 및 파일 읽기를 실행하여 요청을 더 빠르게 처리할 수 있습니다(파일이 기존 디렉토리 구조에서 발견된다고 가정).

또 다른 이점은 안전하다는 것입니다. 디렉터리 수준 구성 액세스를 배포하면 적절하게 수행할 수 있는지 여부에 관계없이 개별 사용자에게 보안 책임이 분산됩니다. 관리자가 웹 서버를 완전히 제어할 수 있도록 하면 다른 사람에게 액세스 권한이 부여될 때 발생할 수 있는 몇 가지 보안 실수를 피할 수 있습니다.

이러한 문제가 우려되는 경우 Apache에서 .htaccess 해석을 비활성화할 수 있음을 명심하십시오.

파일 VS URI 기반 해석

NGINX는 웹 서버 및 프록시 서버로 작동하도록 설계되었습니다. 이 두 작업에 필요한 아키텍처로 인해 필요할 때 파일 시스템으로 변환하는 주로 URI와 함께 작동합니다.

이는 경우에 따라 NGINX 구성 파일이 빌드되고 처리되는 방식에서 볼 수 있습니다.
NGINX에는 파일 시스템 디렉토리에 대한 구성을 지정하는 방법이 없으므로 URI를 구문 분석합니다.

예를 들어 서버 및 위치 블록은 NGINX의 가장 중요한 구성 블록입니다. 서버 블록은 요청된 호스트를 해석하는 역할을 하는 반면 위치 블록은 호스트와 포트 뒤의 URI 부분을 일치시키는 역할을 합니다. 요청은 이제 파일 시스템 위치가 아닌 URI로 처리됩니다.

정적 파일에 대한 모든 요청은 결국 디스크의 한 위치에 매핑되어야 합니다. NGINX는 먼저 요청을 처리할 서버 및 위치 블록을 선택한 다음 문서 루트를 URI와 결합하여 설정에 따라 필요에 따라 수정합니다.

비슷하게 보일 수 있지만 요청을 파일 시스템 위치가 아닌 주로 URI로 해석하면 NGINX가 웹, 메일 및 프록시 서버 역할을 하기가 더 쉽습니다. NGINX는 특정 요청 패턴에 응답하는 방법을 정의하여 설정됩니다. NGINX는 요청을 전달할 준비가 될 때까지 파일 시스템을 검사하지 않습니다. 이것이 .htaccess 파일이 지원되지 않는 이유입니다.

모듈

NGINX에도 모듈 시스템이 있지만 Apache와는 상당히 다릅니다. NGINX의 모듈은 동적으로 로드할 수 없으므로 선택하여 핵심 소프트웨어로 컴파일해야 합니다.
그 결과 NGINX는 많은 사용자에게 훨씬 덜 적응할 것입니다. 이것은 배포의 표준 패키징 체계를 벗어나 자신이 구축한 소프트웨어를 유지 관리하는 것을 주저하는 사용자에게 특히 해당됩니다. 대부분의 배포판 패키지에는 가장 일반적으로 사용되는 모듈이 포함되어 있지만 비표준 모듈이 필요한 경우 소스에서 직접 서버를 빌드해야 합니다.

반면에 NGINX 모듈은 사용하려는 기능만 포함하여 서버에서 원하는 것을 정확하게 지정할 수 있기 때문에 여전히 매우 가치가 있습니다. 일부 사용자는 임의의 구성 요소를 서버에 연결할 수 없기 때문에 접근 방식이 더 안전하다고 생각할 수도 있습니다. 귀하의 서버가 이것이 가능한 상황에 놓이게 된다면 그것은 거의 확실히 이미 손상된 것입니다.

Apache 모듈에서와 마찬가지로 NGINX 모듈에서도 동일한 기능을 사용할 수 있습니다. 프록시 지원, 압축, 속도 제한, 로깅, 다시 쓰기, 지리적 위치, 인증, 암호화, 스트리밍 및 메일 기능은 모두 NGINX 모듈을 통해 사용할 수 있습니다.

지원, 호환성, 생태계 및 문서

NGINX는 고성능 때문에 더 많은 사람들이 사용함에 따라 인기를 얻고 있지만 여전히 특정 중요한 영역에서 따라잡아야 할 부분이 있습니다.

초기 개발 및 문서의 대부분이 러시아어로 작성되었기 때문에 과거에는 NGINX에 대한 실질적인 영어 문서를 찾기가 어려웠습니다. 문서는 프로젝트에 대한 관심이 높아짐에 따라 구체화되었으며 현재 NGINX 사이트 및 타사를 통해 사용할 수 있는 관리 리소스가 많이 있습니다.

타사 앱에 대한 지원 및 문서가 보다 광범위하게 제공되고 있으며 패키지 유지 관리자는 일부 상황에서 Apache 및 NGINX를 자동 구성하기 위한 옵션을 제공하기 시작했습니다. 다른 소프트웨어와 함께 작동하도록 NGINX를 구성하는 것은 일반적으로 지원 없이도 프로젝트의 요구 사항(권한, 헤더 등)이 문서화되어 있는 한 간단합니다.

NGINX의 장점

NGINX 웹 서버는 간단하고 가볍고 빠릅니다. 트래픽이 많은 웹 사이트를 위해 특별히 설계되었습니다.

• 적은 CPU와 메모리를 사용하는 이벤트 중심의 비차단 아키텍처를 사용합니다.
• 여기에는 정적 콘텐츠에 대한 많은 최적화 및 제공 옵션이 포함됩니다. 결과적으로 Apache보다 2.5배 더 빠르게 정적 콘텐츠를 제공하고 메모리를 덜 사용합니다.
• 다중 프로세서 시스템에서 훌륭하게 수행됩니다.
• 내장된 구성 옵션으로 DDoS 공격을 방지합니다.

NGINX의 단점

• 동적 콘텐츠는 기본적으로 처리할 수 없습니다.
• 더 적은 수의 모듈을 사용할 수 있습니다.
• Linux 및 Unix 운영 체제가 지원되지만 Windows 지원은 제한됩니다.
• Apache에서 지원하는 .htaccess 파일은 NGINX에서 지원하지 않습니다.
• 로그 모니터링 소프트웨어의 부족 - 수동으로 탐색해야 하는 파일에 로그를 저장하기만 하면 됩니다.

Apache와 NGINX를 함께 사용하려면

Apache와 NGINX의 장단점을 검토한 후에는 어떤 서버가 귀하의 요구에 더 적합한지 결정할 수 있어야 합니다. 그러나 많은 사용자는 두 서버를 함께 사용하면 각 서버의 이점을 활용할 수 있습니다.

이 협력을 위한 표준 구성은 NGINX를 Apache 앞에서 역방향 프록시로 사용하는 것입니다. 이렇게 하면 NGINX가 모든 클라이언트 요청을 처리할 수 있습니다. 이를 통해 NGINX의 빠른 처리 속도와 많은 수의 연결을 한 번에 관리할 수 있습니다.

파일은 NGINX가 탁월한 정적 콘텐츠를 위해 클라이언트에 신속하고 직접적으로 제공됩니다. NGINX는 PHP 스크립트와 같은 동적 콘텐츠에 대한 요청을 Apache에 프록시하여 결과를 처리하고 렌더링된 페이지를 제공합니다. 그러면 자료는 NGINX를 통해 클라이언트에게 반환될 수 있습니다.

많은 사용자에게 이 디자인은 NGINX가 분류 기계 역할을 할 수 있게 해주기 때문에 잘 작동합니다. 처리할 수 있는 모든 요청을 처리하고 처리 방법을 모르는 요청을 전달합니다. Apache 서버가 처리하도록 요청되는 요청 수를 줄임으로써 Apache 프로세스 또는 스레드가 점유될 때 발생하는 차단을 일부 줄일 수 있습니다.

필요에 따라 백엔드 서버를 더 추가하여 이 배열로 확장할 수 있습니다. NGINX는 요청을 서버 풀로 전달하도록 설정하여 구성의 내결함성과 성능을 향상시킬 수 있습니다.

Apache와 NGINX를 언제 사용합니까?

이 글에서 설명한 것처럼 Apache와 NGINX는 모두 강력하고 적응력이 뛰어나며 만능 웹 서버입니다. 트래픽이 많은 웹 사이트의 경우 Apache는 동적 자료를 제공하는 데 가장 적합하지만 NGINX는 정적 콘텐츠 또는 미디어 스트림을 제공하는 데 가장 적합합니다. 다음과 같이 간단합니다.

아파치를 언제 사용할 수 있습니까?

• 공유 호스팅 계획을 사용 중인 경우.
• 자원이 풍부한 도움이 되는 커뮤니티에 감사를 표한다면 바로 여기입니다.
• Apache는 설정이 간단하기 때문에 웹 개발자들 사이에서 인기가 있습니다.

NGINX는 언제 사용할 수 있습니까?

• VPS 또는 전용 서버가 있는 경우.
• 정적인 콘텐츠가 많은 인기 있는 웹사이트의 소유자입니다.
• 들어오는 트래픽을 관리하고 더 느린 업스트림 서버에 배포하려는 경우.

Apache vs. NGINX: 2022년 서버로 어떤 것을 선택해야 합니까?

호스팅 회사에서 제공하는 것이 무엇이든 사용해야 합니다. 많은 상황에서 옵션이 없습니다. 많은 웹 제공업체가 동일한 전략을 따르며 Apache와 NGINX 사이에서 결정하는 경우 따라야 합니다.

• Apache는 지속적인 설정이 필요한 서버를 호스팅하거나 사용자에게 구성 옵션을 제공하려는 경우 좋은 선택입니다.
• 반면에 NGINX는 초고속 성능, 견고한 보안, 사용자가 아닌 구성 관리 기능을 원하는 경우에 적합한 방법입니다.

Apache는 기본 아키텍처로 인해 성능 면에서 더 많은 RAM을 차지할 수 있습니다. 트래픽이 많은 경우, 특히 관리할 정적 자료가 많은 경우 NGINX가 더 잘 수행됩니다.

따라서 캐싱에 의존하여 콘텐츠를 저장하고 제공하는 경우 NGINX가 이상적인 솔루션이 될 수 있습니다. NGINX는 동적 자료를 제공할 수 없음을 기억하십시오. 따라서 성능은 서버가 사용하는 프록시의 효율성에 영향을 받습니다.

결론

보시다시피 Apache와 NGINX는 강력하고 적응력이 뛰어납니다. 개별 요구 사항을 평가하고 예상되는 패턴을 테스트하는 것이 적합한 서버를 선택하기 위한 기본 기준입니다.

이러한 프로젝트에는 원시 성능, 기능 및 각각을 구현하는 데 걸리는 시간에 상당한 차이가 있습니다. 그러나 종종 무시해서는 안되는 일련의 절충안의 결과입니다. 마지막으로 만능 웹 서버는 없으므로 필요에 맞는 옵션을 선택하십시오.