Nginx vs Apache - Có bất kỳ so sánh sử dụng thực tế và thống kê ngoài kia không?

Tôi có một máy chủ mới để chơi và tôi đang nhìn chằm chằm vào một khung vẽ trống. Tôi có thể đặt bất cứ thứ gì tôi muốn lên nó. Mặc dù tôi cảm thấy thoải mái với Apache, tôi vẫn nghe cách nginx có thể xử lý lưu lượng truy cập nhiều hơn so với Apache, theo các yếu tố 10, 100, thậm chí nhiều hơn. Không chỉ vậy, nó "nhanh hơn nhiều."

Khi tôi tìm kiếm các bài báo tôi có thể tìm thấy rất nhiều thứ không liên quan đến Drupal. Hoặc, khi tôi bắt gặp một bài viết liên quan đến Drupal, đó là 1) tệp cấu hình của ai đó với một nỗ lực nhanh chóng để giải thích cách thiết lập nó, hoặc 2) có ai đó nói "không, đừng sử dụng nginx, hãy đi với Apache với PHP fcgid "nhưng không bao giờ có lời giải thích tại sao.

Vậy, khi nói đến Drupal, thực tế ở đây là gì?

Ví dụ, tôi đang tìm kiếm một cái gì đó dọc theo dòng bài viết 2bits.com này. Ở đây, tác giả đã có một cái nhìn khá sâu rộng về Apache mod_php vs Apache với fcgid, cân nhắc ưu và nhược điểm của từng loại, và cung cấp một nghiên cứu trường hợp để minh họa tác động trong thế giới thực. Có đủ thông tin trong bài viết này để tôi đưa ra quyết định có học thức về cách tiếp cận nào là tốt nhất cho tình huống của tôi.

Trong khi tác giả đó so sánh mod_php với fcgid, tôi đang tìm kiếm cùng một kiểu nhìn thế giới thực, toàn diện về Apache vs Nginx.

Bất cứ ai cũng chuyển sang Nginx và bị "thổi bay" bởi sự khác biệt mà nó tạo ra so với Apache? Ngay cả đối với các môi trường được tối ưu hóa cao đã sử dụng APC, Memcache và bộ nhớ đệm tích cực như Varnish, khi biến duy nhất thay đổi là thay thế Apache bằng Nginx, cũng không tạo ra sự khác biệt trong việc đầu tư vào công nghệ thay thế mới hơn này ?

Trang web sẽ đi trên máy chủ này nhận được 2 triệu PV mỗi tháng. LAMP stack chạy Cent OS 6. CPU 4 lõi với 8 GIGS ram. Memcached và APC sẽ là một phần của hỗn hợp. Không có gì đặc biệt về cài đặt Drupal - về cơ bản là vanilla 7 với khoảng 50 mô-đun.

Nói đúng ra, điều này không trả lời câu hỏi bạn đang hỏi. Tôi hy vọng nó vẫn hữu ích.

Apache / Nginx / Lighttpd / máy chủ web khác. Có vấn đề nào tôi chọn? Tóm lại, Không .

Câu trả lời dài hơn nhiều:

Nếu , và chỉ khi, bạn có một tỷ lệ rất lớn người dùng của bạn đang đăng nhập, bạn nên quan tâm đến tất cả về hiệu suất của máy chủ web của bạn. Nếu người dùng của bạn ẩn danh, bất kỳ sự khác biệt nào về mặt lý thuyết mà bạn có thể rút ra từ việc tối ưu hóa ở các lớp đó đều tuyệt đối so với việc làm cho tài nguyên của bạn được lưu trữ tốt hơn. Nếu các tệp css của bạn có các tiêu đề bộ đệm phù hợp trên chúng, UA thậm chí sẽ không yêu cầu chúng lần thứ hai. Đó là vấn đề. Nếu bạn có thể lưu trữ các trang của mình trong Varnish hoặc một giải pháp phần mềm tương tự, thì việc phục vụ trang đó là vấn đề tìm kiếm băm, sau đó trả lại một khối dữ liệu lớn trực tiếp từ RAM. Đó là vấn đề. Trong cả hai kịch bản này, trình nền HTTP thậm chí không bao giờ tham gia, PHP không được gọi. Drupal không bootstrap. Không có bộ mô-đun lớn nào phải được tải vào RAM, không có truy vấn cơ sở dữ liệu tốn thời gian nào được thực hiện.

Khi bạn thực hiện tải trang đầy đủ, từ bộ đệm lạnh, cho người dùng đã đăng nhập, trên một trang phức tạp; rất nhiều thứ đang diễn ra Có, máy chủ web có liên quan đến việc xử lý yêu cầu đến, đặt một số tiêu đề và chuyển phản hồi lại. Nhưng thời gian, thậm chí không liên quan trong bối cảnh Drupal chạy bootstrap đầy đủ và đưa ra phản hồi của nó. Có thể có hàng trăm truy vấn cơ sở dữ liệu đang được thực thi. Logic rất phức tạp trong PHP được đánh giá bởi trình phân tích cú pháp. Rất nhiều mô-đun đang được tải vào RAM. Cải thiện hiệu suất của bất kỳ điều nào trong số đó, có nhiều khả năng đóng góp nghiêm trọng cho hiệu suất.

Để tranh luận: giả sử bạn đã dành nhiều thời gian để tối ưu hóa mọi thứ khác.

1. Bạn chạy APC (Hoặc Trình tối ưu hóa + ) và phiên bản PHP mới nhất và nhanh nhất.
2. Các truy vấn DB rất ít.
3. Logic PHP đã được giảm.
4. Bạn lưu trữ những gì bạn có thể trong Varnish.
5. Bạn đã cấu trúc lại toàn bộ trang web của mình để bạn có thể lưu trữ nhiều phía máy khách và thực hiện nhiều thao tác nặng trong ECMAScript .

Nếu bạn có nhiều người dùng đã đăng nhập và bạn đã xử lý tất cả những điều trên, thì có lẽ bạn có thể tạo sự khác biệt nhưng điều chỉnh hiệu suất hoặc thay thế máy chủ web của bạn. Tuy nhiên, đoán xem. Trang web của bạn rất phức tạp và mô hình sử dụng của những người dùng cụ thể của bạn, là duy nhất . Không có câu trả lời chung chung. Bạn sẽ cần thiết lập tất cả các máy chủ web khác nhau đằng sau bộ cân bằng tải và xem cách chúng hoạt động, theo kịch bản của bạn .

Trên đây là một nỗ lực để đạt được kết luận một cách hợp lý rằng việc dành thời gian tối ưu hóa hiệu suất của máy chủ web có thể là việc sử dụng thời gian không tốt. Tôi rất thích có ai đó chọn lỗ hổng ở trên, tôi có thể sẽ học được điều gì đó mới từ nó. :)

Một số lưu ý khác:

1. Trong bài phát biểu của DrupalCon Copenhagen , người sáng tạo PHP Rasmus Lerdorf , sử dụng chính Nginx, nói về chủ đề hiệu suất của Drupal, nói "Mọi người luôn hỏi tôi về các máy chủ web ... thực sự không có vấn đề gì, máy chủ web không liên quan lắm" . (Khoảng 26:30 trong video)
2. Facebook đã dành vô số thời gian để viết Hiphop , một cơ sở mã lớn hơn đáng kể so với chính Drupal, để tăng tốc mã PHP lên 100% "sởi". Tôi đã kiểm tra Hiphop $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1và thấy nó bao gồm 1.512.481 dòng mã. Đó là một khối lượng công việc hoàn toàn điên rồ được đưa vào để cải thiện tốc độ của PHP. Tôi đoán đó là vì tốc độ của PHP rất quan trọng đối với họ.
3. Tôi đã đề cập rằng bộ nhớ đệm tốt sẽ có tác dụng lớn hơn nhiều trong việc điều chỉnh máy chủ web?
4. Với việc phát hành Apache 2.4, Jim Jagielski về cơ bản tuyên bố rằng Apache 2.4 nhanh hơn các máy chủ dựa trên sự kiện .
5. Tôi đã đạt được hiệu suất và khả năng mở rộng của Drupal với Nhóm ước mơ , nơi câu hỏi này xuất hiện. Tất cả các câu trả lời về việc chọn, không liên quan đến hiệu suất. Những thứ như "Cái nào bạn đã biết cách cấu hình" và "Cái nào sẽ cho phép bạn xây dựng ngăn xếp công nghệ đơn giản nhất", là một trong những lý do được đề cập để lựa chọn khác. Hiệu suất đã không nhập hình ảnh.

OK, mặc dù câu hỏi này đã được trả lời, nhưng tôi lại cần một lần nữa, chủ yếu là vì tôi không thích hàm ý của những câu trả lời này rằng nó không tạo ra sự khác biệt và vì là một nhà phát triển web, tôi ghét lưu trữ bộ nhớ cache với niềm đam mê .

Sự khác biệt giữa Apache và nginx không phải là "chúng có thể phục vụ yêu cầu nhanh đến mức nào" mà là chúng có thể phục vụ bao nhiêu yêu cầu trên cùng một lượng phần cứng (đặc biệt là với các nguồn tài nguyên hạn chế), đó là một điều khác biệt.

Apache là một máy chủ dựa trên quy trình. Có nghĩa là nó tạo ra một quy trình cho mọi yêu cầu. Nginx là một máy chủ dựa trên sự kiện, có nghĩa là sử dụng vòng lặp sự kiện (không đồng bộ) thay vì các quy trình hoặc luồng.

Và trong khi một máy chủ dựa trên quy trình (như Apache) có thể thực hiện ít nhiều ngang bằng với một máy chủ dựa trên sự kiện không đồng bộ (như nginx) trong các tải nhẹ, thì dưới các tải nặng hơn như ví dụ 10'0000 yêu cầu đồng thời, nginx chỉ sử dụng một số ít megabyte RAM, trong khi Apache chỉ cần vài trăm megabyte cho máy chủ web (không bao gồm ứng dụng web, vốn cần nhiều nguồn tài nguyên hơn nhiều), nếu nó hoàn toàn có thể làm được.

Vì vậy, dưới tải nặng hơn, bạn sẽ thấy Apache tiêu thụ quá nhiều RAM, điều này làm giảm đáng kể hiệu năng.

Đáng kể hơn, mức tiêu thụ RAM cao hơn có nghĩa là Apache có thể phục vụ ít yêu cầu hơn trên cùng một phần cứng so với nginx, điều đó có nghĩa là Apache yêu cầu nhiều phần cứng hơn cho cùng một lượng người dùng, có nghĩa là bạn có TCO cao hơn (tổng chi phí sở hữu) với Apache hơn với nginx, điều này làm giảm ROI (lợi tức đầu tư) của bạn.

Tổng bộ nhớ được sử dụng bởi các kết nối đồng thời X (ít hơn là tốt hơn)

Các yêu cầu có thể được phục vụ mỗi giây tại X kết nối đồng thời trên 1 bộ phần cứng (nhiều hơn là tốt hơn)

Nguồn: ApacheBench, bởi dreamhost.com

Xem thêm văn bản kỹ thuật số đại dương này .
Rõ ràng, nó phụ thuộc vào Kiến trúc Xử lý kết nối mà bạn chọn cho Apache.

Tôi đã chuyển từ Apache sang Nginx / PHP-FPM vài tháng trước.

Tôi đã thực hiện một số băng ghế dự bị với một trang web drupal, và thử nghiệm một số trường hợp sử dụng. Trên máy chủ VPS có 1 CPU và RAM 512 Mo

Drupal chỉ có bộ nhớ cache

Nginx

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)

Apache

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 với bộ nhớ cache và boost

Nginx

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

Apache

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

điểm chuẩn cho người dùng Xác thực (tải trang)

Nginx

Page load times : 2.85 s

Apache

Page load times : 5.4 s

Nhưng sức mạnh của Nginx là hệ thống bộ nhớ cache

Drupal không có Boost và Nginx với hệ thống cache được kích hoạt

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

Bạn nên sử dụng Nginx cấu hình của perusio cho Drupal

Dưới đây là bài kiểm tra hiệu năng cho mười máy chủ web / biến (ví dụ: Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Ba trong số các bài kiểm tra liên quan đến Drupal.

Tôi nghĩ Hiawatha có thể là sự lựa chọn tốt nhất. Được cho là có khả năng tương thích Drupal đầy đủ , chú trọng đến bảo mật (DoS, XSS, CSRF, phòng chống tiêm SQL) và tốc độ & dấu chân tương tự như Nginx.

Trong hai trong ba thử nghiệm Drupal, cả Hiawatha và Nginx đều vượt trội hơn Apache khoảng 150%, nhưng trong thử nghiệm tĩnh Drupal, Apache vượt trội so với Nginx, trong khi Hiawatha vượt trội hơn gói khoảng 10%.

Tôi sẽ không treo mũ trong bất kỳ thử nghiệm nào trong số này, nhưng nó mang lại cho người ta một cái nhìn về hiệu suất trong các tình huống sử dụng khác nhau. Tôi nghĩ rằng hiệu suất một mình không nên được xem xét duy nhất. Sự ổn định và bảo mật có thể là yếu tố quan trọng hơn.

Đây là kết quả kiểm tra tải cho drupal chạy trên cùng một phần cứng nhưng với các máy chủ web khác nhau. (nginx và apache)

đây là kết luận của bài kiểm tra này:

trong một lưu lượng lớn với cùng tài nguyên phần cứng, nginx thực hiện cách tốt hơn apache.