Nginx vs Apache - มีการเปรียบเทียบการใช้งานจริงและ statistcs ออกมี?

ฉันมีเซิร์ฟเวอร์ใหม่ให้เล่นด้วยและฉันก็จ้องไปที่ผืนผ้าใบว่างเปล่า ฉันสามารถใส่อะไรก็ได้ที่ฉันต้องการ ในขณะที่ฉันสบายใจกับ Apache ฉันก็ยังคงได้ยินว่า nginx สามารถจัดการปริมาณการใช้งานได้มากกว่า Apache มากเพียงใดโดยปัจจัย 10, 100 และอื่น ๆ อีกมากมาย ไม่เพียงเท่านั้นมันคือ "เร็วกว่ามาก"

เมื่อฉันค้นหาบทความฉันสามารถค้นหาสิ่งต่าง ๆ มากมายที่ไม่เกี่ยวข้องกับ Drupal หรือเมื่อฉันเจอบทความที่เกี่ยวข้องกับ Drupal ก็คือ 1) ไฟล์กำหนดค่าของใครบางคนที่พยายามอธิบายวิธีตั้งค่าอย่างรวดเร็วหรือ 2) มีคนพูดว่า "ไม่ไม่ใช้ nginx ไปกับ Apache กับ PHP fcgid "แต่ก็ไม่มีคำอธิบายว่าทำไม

ดังนั้นเมื่อพูดถึง Drupal ความจริงคืออะไรที่นี่?

ตัวอย่างเช่นฉันกำลังมองหาบางสิ่งบางอย่างตามสายบทความ2bits.comนี้ ที่นี่ผู้เขียนได้ดู Apache mod_php vs Apache อย่างกว้างขวางพร้อมกับ fcgid ชั่งน้ำหนักข้อดีข้อเสียของแต่ละกรณีและให้กรณีศึกษาเพื่อแสดงให้เห็นถึงผลกระทบในโลกแห่งความเป็นจริง มีข้อมูลเพียงพอในบทความนี้สำหรับฉันในการตัดสินใจที่มีการศึกษาว่าวิธีใดเหมาะสมที่สุดสำหรับสถานการณ์ของฉัน

ในขณะที่ผู้เขียนเปรียบเทียบ mod_php กับ fcgid ฉันกำลังมองหาประเภทที่ครอบคลุมและเหมือนจริงในโลกของ Apache vs Nginx

ทุกคนเปลี่ยนไปใช้ Nginx และ "ปลิวไป" ด้วยความแตกต่างที่เกิดขึ้นเมื่อเทียบกับ Apache แม้สำหรับสภาพแวดล้อมที่ได้รับการปรับให้เหมาะสมอย่างสูงสุดซึ่งใช้ APC, Memcache และการแคชที่ก้าวร้าวเช่น Varnish เมื่อตัวแปรเพียงตัวเดียวที่เปลี่ยนคือการแทนที่ Apache ด้วย Nginx นั้นสร้างความแตกต่างในตัวของมันเองเพื่อลงทุนในเทคโนโลยีใหม่ที่ใหม่กว่านี้ ?

ไซต์ที่จะไปบนเซิร์ฟเวอร์นี้จะได้รับเฉลี่ย 2 ล้าน PV ต่อเดือน LAMP stack ใช้ Cent OS 6. CPU หลัก 4 ตัวพร้อม RAM 8 GIGS Memcached และ APC จะเป็นส่วนหนึ่งของการผสมผสาน ไม่มีอะไรพิเศษเกี่ยวกับการติดตั้ง Drupal - โดยทั่วไปคือวานิลลา 7 ที่มีโมดูลประมาณ 50 รายการ

พูดอย่างเคร่งครัดนี่ไม่ได้ตอบคำถามที่คุณถาม ฉันหวังว่ามันจะเป็นประโยชน์

Apache / Nginx / Lighttpd / เว็บเซิร์ฟเวอร์อื่น ๆ มันเป็นสิ่งสำคัญหรือไม่ที่ฉันเลือก ในระยะสั้นไม่มี

คำตอบที่ยาวกว่านี้มาก:

ถ้าและถ้าหากคุณมีผู้ใช้จำนวนมากที่เข้าสู่ระบบหากคุณสนใจเกี่ยวกับประสิทธิภาพของเว็บเซิร์ฟเวอร์ของคุณ หากผู้ใช้ของคุณไม่ระบุชื่อความแตกต่างใด ๆ ที่คุณสามารถได้มาจากการเพิ่มประสิทธิภาพที่เลเยอร์ pales สัมบูรณ์ในทางทฤษฎีใด ๆ เมื่อเทียบกับการทำให้ทรัพยากรของคุณแคชได้ดีขึ้น หากไฟล์ css ของคุณมีส่วนหัวแคชที่เหมาะสม UA จะไม่ถามพวกเขาเป็นครั้งที่สอง ที่สำคัญ. หากคุณสามารถแคชหน้าเว็บของคุณในวานิชหรือโซลูชันซอฟต์แวร์ที่คล้ายกันการแสดงหน้านั้นเป็นเรื่องของการแฮช - ค้นหาแล้วส่งคืนก้อนข้อมูลขนาดใหญ่โดยตรงจาก RAM ที่สำคัญ. ในทั้งสองกรณีนี้ HTTP daemon จะไม่เกี่ยวข้องแม้แต่ PHP จะไม่ถูกเรียกใช้ Drupal ไม่บู๊ตสแตรป ไม่มีชุดโมดูลขนาดใหญ่ที่ต้องโหลดเข้าสู่ RAM ไม่ต้องดำเนินการสืบค้นฐานข้อมูลเสียเวลา

เมื่อคุณทำการโหลดแบบเต็มหน้าจากแคชเย็นสำหรับผู้ใช้ที่เข้าสู่ระบบในหน้าซับซ้อน มีหลายสิ่งหลายอย่างเกิดขึ้น ใช่เว็บเซิร์ฟเวอร์มีส่วนร่วมในการจัดการกับคำขอที่เข้ามาตั้งค่าบางส่วนและส่งผ่านการตอบกลับ แต่เวลาที่ใช้ไม่เกี่ยวข้องแม้แต่กับบริบทของ Drupal ที่ใช้ bootstrap แบบเต็มและแสดงผลการตอบสนอง อาจมีการสืบค้นฐานข้อมูลหลายร้อยรายการ ตรรกะที่ซับซ้อนสูงใน PHP ถูกประเมินโดยตัวแยกวิเคราะห์ โมดูลจำนวนมากถูกโหลดเข้าสู่ RAM การปรับปรุงประสิทธิภาพของสิ่งเหล่านั้นมีแนวโน้มที่จะมีส่วนร่วมอย่างจริงจังต่อประสิทธิภาพ

เพื่อการโต้แย้ง: สมมติว่าคุณใช้เวลามากมายในการปรับปรุงทุกอย่างให้เหมาะสม

1. คุณเรียกใช้APC (หรือเครื่องมือเพิ่มประสิทธิภาพ + ) และ PHP รุ่นล่าสุดและเร็วที่สุด
2. DB- แบบสอบถามมีน้อย
3. ลอจิก PHP ลดลง
4. คุณแคชสิ่งที่คุณทำได้ในวานิช
5. คุณได้อีกครั้งโครงสร้างทั้งเว็บไซต์ของคุณเพื่อให้คุณสามารถแคชด้านลูกค้าจำนวนมากและทำจำนวนมากของการยกของหนักในECMAScript

หากคุณมีผู้ใช้ที่เข้าสู่ระบบจำนวนมากและคุณได้จัดการกับทุกอย่างที่กล่าวมาข้างต้นคุณอาจสร้างความแตกต่างได้ แต่ปรับประสิทธิภาพหรือเปลี่ยนเว็บเซิร์ฟเวอร์ของคุณ อย่างไรก็ตามคาดเดาสิ่งที่ เว็บไซต์ของคุณมีความซับซ้อนมากและรูปแบบการใช้งานของผู้ใช้โดยเฉพาะอย่างยิ่งของคุณเป็นที่ไม่ซ้ำกัน ไม่มีคำตอบทั่วไป คุณจะต้องติดตั้งเว็บเซิร์ฟเวอร์ที่แตกต่างกันอยู่เบื้องหลัง balancer โหลดและดูว่าพวกเขาประพฤติภายใต้สถานการณ์ของคุณ

ด้านบนเป็นความพยายามในการเข้าถึงข้อสรุปอย่างมีเหตุผลว่าการใช้เวลาให้เกิดประโยชน์สูงสุดการปรับแต่งเว็บเซิร์ฟเวอร์น่าจะเป็นการใช้เวลาที่ไม่ดี ฉันชอบที่จะมีคนเลือกหลุมในข้างต้นแม้ว่าฉันอาจจะเรียนรู้สิ่งใหม่จากมัน :)

หมายเหตุอื่น ๆ :

1. ในระหว่างการกล่าวสุนทรพจน์ของDrupalCon Copenhagenผู้สร้าง PHP Rasmus Lerdorfโดยใช้ Nginx พูดในหัวข้อของประสิทธิภาพการทำงานของ Drupal กล่าวว่า "ผู้คนมักจะถามฉันเกี่ยวกับเว็บเซิร์ฟเวอร์ ... มันไม่สำคัญเลยเว็บเซิร์ฟเวอร์ค่อนข้างไม่เกี่ยวข้องเลย" . (ประมาณ 26:30 น. ในวิดีโอ)
2. Facebook ใช้เวลานับไม่ถ้วนในการเขียนHiphopซึ่งเป็นฐานรหัสที่ใหญ่กว่า Drupal เองอย่างมากสำหรับการเร่งโค้ด PHP ด้วย "เลวร้าย" 100% ฉันตรวจสอบ 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, จิม Jagielski พื้นอ้างว่า Apache 2.4 จะเร็วกว่าเซิร์ฟเวอร์ตามเหตุการณ์
5. ฉันได้เข้าร่วมDrupal Performance และ Scalability กับ The Dream Teamที่มีคำถามนี้เกิดขึ้น คำตอบทั้งหมดเกี่ยวกับการเลือกไม่เกี่ยวข้องกับประสิทธิภาพ สิ่งต่าง ๆ เช่น "อันไหนที่คุณรู้อยู่แล้วว่าจะตั้งค่าอย่างไร" และ "อันไหนที่จะทำให้คุณสามารถสร้างสแต็คเทคโนโลยีที่ง่ายที่สุด" ได้ด้วยเหตุผลหลายประการที่กล่าวมา การแสดงไม่ได้เข้ารูป

ตกลงแม้ว่าคำถามนี้จะได้รับคำตอบแล้ว แต่ฉันก็ต้องชำระอีกครั้งหลักเพราะฉันไม่ชอบความหมายของคำตอบเหล่านี้ว่ามันไม่ได้สร้างความแตกต่างและเพราะในฐานะนักพัฒนาเว็บฉันเกลียดการแคชด้วยความหลงใหล .

ความแตกต่างระหว่าง Apache และ nginx นั้นไม่มาก "เร็วแค่ไหนที่พวกเขาสามารถให้บริการตามคำขอ" แต่มีกี่คำขอที่พวกเขาสามารถให้บริการในจำนวนเท่ากันของฮาร์ดแวร์ (โดยเฉพาะอย่างยิ่งกับทรัพยากรที่ จำกัด ) ซึ่งค่อนข้างแตกต่างกัน

Apache เป็นเซิร์ฟเวอร์ที่ใช้กระบวนการ ความหมายมันทำให้กระบวนการสำหรับทุกคำขอ Nginx เป็นเซิร์ฟเวอร์ที่ใช้เหตุการณ์ซึ่งมีความหมายว่าจะใช้ห่วงเหตุการณ์ (แบบอะซิงโครนัส) แทนกระบวนการหรือเธรด

และในขณะที่เซิร์ฟเวอร์ที่ใช้กระบวนการ (เช่น Apache) สามารถทำงานได้มากกว่าหรือน้อยกว่าด้วยเซิร์ฟเวอร์แบบอะซิงโครนัสเหตุการณ์ (เช่น nginx) ภายใต้การโหลดแบบเบาภายใต้การโหลดที่มีน้ำหนักมากเช่นคำขอ 10'0000 พร้อมกัน เมกะไบต์ของ RAM ในขณะที่ Apache ต้องการหลายร้อยเมกะไบต์สำหรับเว็บเซิร์ฟเวอร์เพียงอย่างเดียว (ไม่รวมถึงเว็บแอปพลิเคชันซึ่งต้องการ ressources มากกว่านั้น) หากมันสามารถทำได้เลย

ดังนั้นภายใต้การโหลดที่หนักกว่าคุณจะเห็น Apache กิน RAM มากเกินไปซึ่งทำให้ประสิทธิภาพลดลงอย่างน่าประหลาดใจ

อย่างมีนัยสำคัญยิ่งกว่าการใช้ RAM ที่สูงขึ้นหมายความว่า Apache สามารถตอบสนองคำขอน้อยลงบนฮาร์ดแวร์เดียวกันได้มากกว่า nginx ซึ่งหมายความว่า Apache ต้องการฮาร์ดแวร์เพิ่มเติมสำหรับจำนวนผู้ใช้เท่ากันซึ่งหมายความว่าคุณมี TCO สูงกว่า (ต้นทุนการเป็นเจ้าของทั้งหมด) กับ Apache มากกว่ากับ nginx ซึ่งช่วยลด ROI ของคุณ (ผลตอบแทนจากการลงทุน)

หน่วยความจำทั้งหมดที่ใช้โดยการเชื่อมต่อพร้อมกัน X (น้อยกว่าดีกว่า)

คำขอที่สามารถให้บริการต่อวินาทีที่การเชื่อมต่อ X พร้อมกันบนฮาร์ดแวร์ 1 ชุด (ดีกว่าดีกว่า)

ที่มา: ApacheBench โดยdreamhost.com

ดูการเขียนมหาสมุทรดิจิตอลนี้ด้วย
เห็นได้ชัดว่ามันขึ้นอยู่กับสถาปัตยกรรมการจัดการการเชื่อมต่อที่คุณเลือกสำหรับ Apache

ฉันเปลี่ยนจาก Apache เป็น Nginx / PHP-FPM ไม่กี่เดือนที่ผ่านมา

ฉันทำ benchmarck กับเว็บไซต์ drupal และทดสอบกรณีการใช้งานหลายอย่าง บนเซิร์ฟเวอร์ VPS ที่มี 1 CPU และ 512 Mo RAM

Drupal ด้วยแคชเท่านั้น

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)

อาปาเช่

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 พร้อมแคชและบูสต์

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

อาปาเช่

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

มาตรฐานสำหรับผู้ใช้รับรองความถูกต้อง (โหลดหน้า)

Nginx

Page load times : 2.85 s

อาปาเช่

Page load times : 5.4 s

แต่พลังของ Nginx คือระบบแคช

Drupal ที่ไม่มี Boost และ Nginx ที่เปิดใช้งานระบบแคช

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

คุณควรใช้การกำหนดค่า Nginx ของ Perusioสำหรับ Drupal

นี่คือการทดสอบประสิทธิภาพสำหรับสิบเว็บเซิร์ฟเวอร์ / ตัวแปร (เช่น Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee) การทดสอบสามข้อเกี่ยวข้องกับ Drupal

ฉันคิดว่า Hiawatha อาจเป็นตัวเลือกที่ดีที่สุด ควรมีความเข้ากันได้กับ Drupal อย่างเต็มรูปแบบโดยเน้นที่ความปลอดภัย (DoS, XSS, CSRF, การป้องกันการฉีด SQL) และความเร็วและรอยเท้าคล้ายกับ Nginx

ในสองในสามของการทดสอบ Drupal ทั้ง Hiawatha และ Nginx มีประสิทธิภาพสูงกว่า Apache ประมาณ 150% แต่ในการทดสอบ Drupal คงที่ Apache มีประสิทธิภาพเหนือกว่า Nginx เล็กน้อยขณะที่ Hiawatha ทำได้ดีที่สุดแพ็คประมาณ 10%

ฉันจะไม่สวมหมวกในการทดสอบใด ๆ เหล่านี้ แต่จะให้มุมมอง ballpark หนึ่งของประสิทธิภาพในสถานการณ์การใช้งานที่แตกต่างกัน ฉันคิดว่าการแสดงเพียงอย่างเดียวไม่ควรนำมาพิจารณาเท่านั้น ความมั่นคงและความปลอดภัยอาจเป็นปัจจัยที่สำคัญกว่า

นี่คือผลการทดสอบโหลดสำหรับ drupal ที่ทำงานบนฮาร์ดแวร์เดียวกัน แต่มีเว็บเซิร์ฟเวอร์ที่แตกต่างกัน (nginx และ apache)

นี่คือบทสรุปของการทดสอบนี้:

ภายใต้ทราฟฟิกขนาดใหญ่ที่มีทรัพยากรฮาร์ดแวร์เดียวกัน nginx ทำงานได้ดีกว่า apache