Nginx vs Apache-실제 사용량 비교 및 ​​통계가 있습니까?


45

새로운 서버를 가지고 있고 빈 캔버스를 쳐다보고 있습니다. 내가 원하는 것을 넣을 수 있습니다. 아파치에 익숙하지만, nginx가 아파치보다 훨씬 많은 트래픽을 처리하는 방법을 10, 100 배나 더 많이 들었습니다. "훨씬 더 빠릅니다."

기사를 검색하면 Drupal과 관련이없는 많은 것을 찾을 수 있습니다. 또는 Drupal 관련 기사를 보았을 때 1) 누군가의 구성 파일을 설정하는 방법을 빠르게 설명하려고 시도하거나 2) "아니오, nginx를 사용하지 말고 PHP로 Apache를 사용하십시오" fcgid "라고 말하지만 이유에 대한 설명은 없습니다.

Drupal과 관련하여 현실은 무엇입니까?

예를 들어, 나는이 2bits.com 기사를 따라 무언가를 찾고 있습니다. 여기서 저자는 fcgid를 사용하여 Apache mod_php와 Apache를 꽤 광범위하게 살펴보고 각각의 장단점을 측정하고 실제 세계에 미치는 영향을 설명하는 사례 연구를 제공했습니다. 이 기사에는 어떤 상황이 내 상황에 가장 적합한 지에 대한 교육적인 결정을 내릴 수있는 충분한 정보가 있습니다.

그 저자는 mod_php를 fcgid와 비교하지만 Apache와 Nginx에 대한 동일한 유형의 포괄적이고 실제적인 모습을 찾고 있습니다.

누구든지 Nginx로 전환하여 Apache와 비교하여 차이로 인해 "파산"되었습니까? APC, Memcache 및 Varnish와 같은 공격적인 캐싱을 이미 사용하고있는 고도로 최적화 된 환경에서도 변경 사항이 유일한 변수가 Apache를 Nginx로 교체하는 것만으로도 새로운 대안 기술에 대한 투자 가치가 충분히 높아질 때 ?

이 서버로 이동할 사이트는 한 달에 평균 2 백만 PV를받습니다. Cent OS 6을 실행하는 램프 스택. 8 GIGS 램을 갖춘 4 코어 CPU. Memcached와 APC가 혼합의 일부가 될 것입니다. Drupal 설치에는 특별한 것이 없습니다. 기본적으로 약 50 개의 모듈이있는 바닐라 7입니다.


2
성능을 위해 특정 사이트를 조정하려면 다른 사람들의 작업에 의존하는 것보다 자체 테스트를 실행하는 것이 좋습니다. 예를 들어 익명 사용자와 로그인 사용자의 혼합이 주요 요인입니다. 주로 익명 트래픽을받는 사이트의 성능 통계를보고 귀하의 사이트가 그렇지 않다면 귀찮게하지 않을 수도 있습니다. 그러나 사이트에 익명의 트래픽이 많은 경우 내 경험에 따라 웹 서버 앞에 Varnish를 배치하면 서버 뒤에서 실행되는 서버보다 훨씬 큰 차이가 발생합니다.
알프레드 암스트롱

답변:


60

엄밀히 말하면, 이것은 당신이 묻는 질문에 대답하지 않습니다. 어쨌든 도움이되기를 바랍니다.

Apache / Nginx / Lighttpd / 기타 웹 서버 내가 선택한 것이 중요합니까? 즉, 없음 .

훨씬 더 긴 답변 :

만약 , 만 있는 경우웹 서버의 성능에 관심이 있다면 로그인 한 사용자의 비율이 매우 높습니다. 사용자가 익명 인 경우 리소스를 더 캐시 가능하게 만드는 것과 비교할 때 이론적으로 해당 계층에서 절대적으로 최적화하는 것에서 얻을 수있는 차이점이 있습니다. CSS 파일에 적절한 캐시 헤더가 있으면 UA는 두 번째 요청조차하지 않습니다. 중요합니다. Varnish 또는 유사한 소프트웨어 솔루션으로 페이지를 캐시 할 수 있다면 해당 페이지를 제공하는 것은 해시 조회를 수행 한 다음 RAM에서 직접 많은 양의 데이터를 반환해야합니다. 중요합니다. 이 두 가지 시나리오에서 HTTP 데몬은 관여하지 않으며 PHP는 호출되지 않습니다. 드루팔은 부트 스트랩을하지 않습니다. RAM에 큰 모듈 세트를로드 할 필요가 없으며 시간이 많이 걸리는 데이터베이스 쿼리가 실행되지 않습니다.

복잡한 페이지에서 로그인 한 사용자에 대해 콜드 캐시에서 전체 페이지로드를 수행하는 경우 많은 일들이 일어나고 있습니다. 예, 웹 서버는 들어오는 요청을 처리하고 일부 헤더를 설정하고 응답을 다시 전달합니다. 그러나 소요되는 시간은 Drupal이 전체 ​​부트 스트랩을 실행하고 응답을 출력하는 상황과 관련이 없습니다. 수백 개의 데이터베이스 쿼리가 실행될 수 있습니다. PHP의 매우 복잡한 로직은 파서에 의해 평가됩니다. 많은 모듈이 RAM에로드되고 있습니다. 이러한 것들의 성능을 향상 시키면 성능에 크게 기여할 가능성이 훨씬 높습니다.

논쟁을 위해 : 다른 모든 것을 최적화하는 데 많은 시간을 들인 적이 있다고 가정 해 봅시다.

  1. 당신은 실행 APC (또는 최적화 + )와 PHP의 최신 빠른 버전.
  2. DB 쿼리는 거의 없습니다.
  3. PHP 로직이 감소되었습니다.
  4. 니스에서 할 수있는 것을 캐시합니다.
  5. 많은 클라이언트 측을 캐시하고 ECMAScript 에서 많은 작업을 수행 할 수 있도록 전체 사이트를 재구성했습니다 .

로그인 한 사용자가 많고 위의 모든 사항을 처리 한 경우 성능 조정 또는 웹 서버 교체와 달리 차이를 만들 수 있습니다. 그러나 무엇을 추측하십시오. 귀하의 사이트는 매우 복잡하며 특정 사용자의 사용 패턴은 고유 합니다. 일반적인 대답은 없습니다. 로드 밸런서 뒤에 다른 모든 웹 서버를 설정하고 시나리오 에서 서버의 작동 방식을 확인 해야합니다 .

위의 내용은 논리적으로 웹 서버를 최적화하는 데 시간을 보내는 것이 시간을 잘못 사용한다는 결론에 도달하려는 시도였습니다. 나는 누군가 위에서 위의 구멍을 선택하도록하고 싶습니다. 아마도 새로운 것을 배울 것입니다. :)

다른 참고 사항 :

  1. 동안 DrupalCon 코펜하겐 기조 연설 , PHP 작성자 라스무스 러 도프는 , Nginx에 자신을 사용하여, 드루팔 성능의 주제에 말하기, "사람들은 항상 정말, 웹 서버는 거의 관련이없는 문제입니다 않습니다 ... 웹 서버에 대해 물어"고 말했다 . (비디오에서 대략 26:30에)
  2. 페이스 북은 드루팔 자체보다 훨씬 더 큰 코드 기반 인 Hiphop 을 작성하는 데 많은 시간을 썼는데 , 이는 "거의"100 %만큼 PHP 코드를 가속화하는 데 사용되었습니다. 나는 Hiphop을 검사 $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1하여 1.512.481 줄의 코드로 구성되어 있음을 발견했습니다. 그것은 PHP 속도를 향상시키는 데 절대적으로 미친 일입니다. PHP의 속도가 그들에게 크게 중요하기 때문입니다.
  3. 좋은 캐싱이 웹 서버를 조정하는 것보다 훨씬 더 큰 영향을 줄 것이라고 언급 했습니까?
  4. Apache 2.4가 출시되면서 Jim Jagielski는 기본적으로 Apache 2.4가 이벤트 기반 서버보다 빠르다고 주장합니다 .
  5. 나는 드문 팀과 함께 Drupal Performance and Scalability에 주목 했다. 선택할 대상에 대한 모든 답변은 성능과 관련이 없습니다. "어느 쪽을 구성하는 방법을 이미 알고 있습니까?"및 "가장 간단한 기술 스택을 구축 할 수있는 것은 무엇입니까?"와 같은 것들이 다른 하나를 선택하는 이유 중 하나였습니다. 성능이 사진에 입력 되지 않았습니다 .

4
대부분의 CSS, JS 및 이미지 요청이 웹 서버에 닿지 않도록 CDN에 대해 잊지 마십시오.
mpdonadio

훌륭한 포인트! drupal.stackexchange.com/questions/24180/… 을 다시 작성해야한다고 생각 합니다. Apache / Nginx에 대한 논의는 포괄적 인 성능 최적화 목록을 작성하기에 최적의 장소가 아닌 것 같습니다.
Letharion

1
이것은 좋은 대답입니다. 단 하나의 닉픽 : "ECMAScript"와 "JavaScript"를 서로 바꿔 사용할 수 없습니다. ECMAScript보다 JavaScript에 더 많은 것이 있습니다.

캐시가 웹 서버 속도보다 훨씬 중요하다고 말하고 있습니다. 맞춰봐? 웹 서버가 다른 서버보다 적은 메모리를 사용하는 경우 캐싱에 더 많은 RAM을 사용할 수 있습니다. 따라서 모든 RAM을 사용하지 않도록 웹 서버를 올바르게 조정 하는 것이 중요하다고 말할 수 있습니까?
pqnet

적은 RAM을 사용하도록 서버를 조정하는 것은 절대적으로 좋지만 고성능 영역으로 들어 가려고하면 전용 서버에서 니스를 실행하고 있으므로 http 서버와 캐시가 동일한 메모리를 놓고 경쟁하지 않습니다.
Letharion

32

좋아,이 질문에 이미 대답했지만, 나는 다시는 차이를 만들지 않는다는 이러한 답변의 의미를 좋아하지 않기 때문에, 그리고 웹 개발자로서 열정으로 캐싱하는 것을 싫어하기 때문에 다시 한 번 괴롭힘을 당하고 있습니다. .

Apache와 nginx의 차이점은 "요청을 얼마나 빨리 처리 할 수 ​​있는가"가 아니라 같은 양의 하드웨어 (특히 제한된 리소스가있는 경우)에서 처리 할 수있는 요청의 수가 약간 다릅니다.

Apache는 프로세스 기반 서버입니다. 모든 요청에 ​​대해 프로세스를 분기한다는 의미입니다. Nginx는 이벤트 기반 서버이므로 프로세스 또는 스레드 대신 (비동기식) 이벤트 루프를 사용합니다.

그리고 프로세스 기반 서버 (Apache와 같은) 적은 부하에서, 예를 들어 10'0000 개의 동시 요청과 같은 더 무거운 부하에서는 nginx와 같은 비동기 이벤트 기반 서버와 거의 비슷하게 수행 할 수 있지만 nginx는 몇 가지만 사용합니다. 아파치는 웹 서버만으로는 수백 메가 바이트를 필요로하는 반면 (아파트 자체는 훨씬 더 많은 리소스를 필요로하는 웹 애플리케이션은 포함하지 않음) 아파치가 필요한 경우에는 아파치가 필요하다.

따라서로드가 많을수록 Apache가 너무 많은 RAM을 소비하므로 성능이 크게 저하됩니다.

더 큰 RAM 소비는 Apache가 nginx보다 동일한 하드웨어에서 더 적은 요청을 처리 할 수 ​​있음을 의미합니다. 즉, Apache는 동일한 양의 사용자에 대해 더 많은 하드웨어가 필요하므로 TCO (총 소유 비용)가 더 높습니다. nginx보다 Apache로 ROI를 줄입니다 (투자 수익).

X 동시 연결에 사용 된 총 메모리 (적을수록 좋음)

메모리 사용량

1 개의 하드웨어 세트에서 X 동시 연결로 초당 제공 될 수있는 요청 (더 나은 것이 좋습니다)

초당 요청

출처 : ApacheBench, dreamhost.com

이 디지털 바다 작성을 참조하십시오 .
분명히 Apache에 대해 선택한 연결 처리 아키텍처에 따라 다릅니다.


6
"... 얼마나 빨리 요청을 처리 할 수 ​​있는지, 같은 양의 하드웨어에서 얼마나 많은 요청을 처리 할 수 ​​있는지 ..." . 정확히 동일한 하드웨어와 다른 변수를 가진 머신을 감안할 때, 아파치가 200,000 만 제공 할 수있는 nginx로 하루에 1,000,000 명의 사용자에게 서비스를 제공 할 수 있다면 확실히 비용 측면에서 최선의 선택은 nginx입니다. 특정 하드웨어 구성이 주어지면 아파치와 비교하여 nginx가 할 수있는 것 사이에 큰 차이가 있습니까?
blue928

2
현재 릴리스 인 Apache 2.4에는 이벤트 기반 모델이 있습니다. httpd.apache.org/docs/current/mod/event.html
Greg

1
또한 "캐싱을하는 한 괜찮아 질 것"이기 때문에 문제가되지 않는다고 말하는 사람들을 위해 : 캐싱을해야하는 것을 알고 있습니까? 무료 RAM이 필요합니다.
pqnet

나는 "Nginx가 더 굉장하다"라는 일반적인 주장을 자주 보지만, 거의 확실한 증거로이를 뒷받침하는 사람은 거의 없다. 항상 "높은 구성의 nginx 인스턴스가 주식 아파치 서버를 이겼으므로 이제 다른 멋진 아이들처럼 nginx를 사용하기 때문에 멋지다는 것을 증명했습니다." Nginx는 아파치보다 아파치보다 훨씬 나을 수도 있지만, 아직 아무도 그런 사실을 보여주지 못했습니다.
Letharion

@ 레타 리온 : (dreamhost.com에 의해) 완료하고 귀하의 요청에 따라 추가. 이 벤치 마크 결과에서 볼 수 있듯이 nginx는 메모리 효율성이 훨씬 뛰어납니다. 또한 아마 재고 : nginx 인스턴스가 동일한 컴퓨터에서 동일한 벤치 마크에서 내 재고-아파치 인스턴스를 이겼습니다.
Quandary

16

몇 달 전에 Apache에서 Nginx / PHP-FPM으로 전환했습니다.

drupal 웹 사이트로 벤치 마크를 만들고 몇 가지 사용 사례를 테스트했습니다. CPU 1 개 및 512 Mo RAM이있는 VPS 서버에서

캐시 만있는 Drupal

니 진스

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

아파치

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

캐시와 부스트가있는 Drupal

니 진스

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

아파치

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

인증 된 사용자를위한 벤치 마크 (페이지로드)

니 진스

Page load times : 2.85 s

아파치

Page load times : 5.4 s

그러나 Nginx의 힘은 캐시 시스템입니다

캐시 시스템이 활성화 된 Boost 및 Nginx가 없는 Drupal

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Perusio의 구성 Nginx for Drupal을 사용해야합니다


Apache는 어떻게 실행되고, 프리폼, FCGI 등은? 이 테스트를 실행할 때 Apache 구성이 최대한 최적화 되었습니까? 정확히 동일한 PHP 환경이 실행 되었습니까?
mpdonadio

PHP (5.3) 환경은 정확히 동일했습니다. 아파치는 mpm_prefork을 실행되었고, 아파치 설정 (maxclient, MaxSpareServers에, MaxRequestsPerChild 값 등)을 정확하게 PHP5-FPM보다 동일
flocondetoile

4
이들은 좋은 숫자이지만 실제 비교인지 확실하지 않습니다. Apache + FastCGI vs Apache + FCGI + PHPFPM vs Nginx + PHPFPM은 Apache와 Nginx의 차이점을 더 잘 보여줍니다.
mpdonadio

MPD가 지적했듯이 이것은 진정한 비교가 아닙니다. 진정한 그림을 얻으려면 둘 다 PHP-fpm을 실행해야합니다.

1
Nginx는 RAM이 제한된 VPS 계정에 적합합니다. Apache보다 작은 RAM 공간으로 편안하게 작동 할 수 있으므로 (특히 불필요한 모듈을 제거한 경우) opcode 캐시 (APC 또는 PHP 5.5의 내장 OpCache)를 실행하기 위해 RAM이 더 남아 MySQL / Postgres 서버에 제공 데몬에는 큰 버퍼가 있으며 Letharion이 올바르게 지적한 다른 최적화도 중요합니다.
개렛 올브라이트

0

다음은 10 개의 웹 서버 / 변형에 대한 성능 테스트 입니다 (예 : Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). 테스트 중 3 개는 Drupal과 관련이 있습니다.

나는 Hiawatha가 가장 좋은 전반적인 선택이라고 생각합니다. 이 가정 전체 드루팔 호환성을 , Nginx에 유사한 보안에 대한 강조 (DOS, XSS, CSRF, SQL 주입 방지), 및 속도 및 풋 프린트를 가지고있다.

3 개의 Drupal 테스트 중 Hiawatha와 Nginx는 Apache보다 약 150 % 성능이 뛰어나지 만 Drupal 정적 테스트에서는 Apache가 Nginx를 능가하는 반면, Hiawatha는 약 10 % 향상되었습니다.

이러한 테스트에 모자를 쓰지는 않지만 다양한 사용 상황에서 성능에 대한 야구장을 보여줍니다. 성능 만 고려해서는 안된다고 생각합니다. 안정성과 보안이 더 중요한 요소 일 수 있습니다.


0

다음 은 동일한 하드웨어에서 실행되지만 다른 웹 서버에서 실행되는 drupal에 대한 로드 테스트 결과입니다. (nginx와 아파치)

이 테스트의 결론은 다음과 같습니다.

하드웨어 리소스가 동일한 트래픽이 많은 경우 nginx는 아파치보다 성능이 뛰어납니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.