Apache vs NGINX - ใครชนะในแง่ของประสิทธิภาพ?

Apache vs NGINX เป็นหนึ่งในการโต้วาทีที่ร้อนแรงที่สุด (นับตั้งแต่เปิดตัว NGINX) เพราะทั้งสองสิ่งนี้เป็นหนึ่งในเว็บเซิร์ฟเวอร์ที่ใช้บ่อยที่สุดในคำนี้ ตามด้วย LiteSpeed ​​และ OpenLiteSpeed

Apache และ NGINX มีอำนาจเกือบ 60% ของเว็บไซต์ทั่วโลก Apache กับ NGINX มีความคล้ายคลึงกันในแง่ของประสิทธิภาพและคุณสมบัติ สถาปัตยกรรม ความปลอดภัย และประสิทธิภาพ ในทางกลับกัน ต่างกันทั้งหมด

การเลือกระหว่างสองเซิร์ฟเวอร์นี้อาจเป็นเรื่องยากเพราะทั้งสองเซิร์ฟเวอร์นั้นยอดเยี่ยม เนื่องจากเว็บเซิร์ฟเวอร์แต่ละแห่งมีข้อดีและข้อเสียต่างกัน ดังนั้นจึงต้องสร้างตัวเลือกที่ดีที่สุดเท่าที่จะเป็นไปได้

คุณยังสามารถตรวจสอบการอภิปราย openlitespeed กับ nginx ได้ที่นี่

การเปรียบเทียบความเร็ว Apache กับ NGINX

ก่อนที่จะเจาะลึกในการอภิปราย Apache กับ NGINX ก่อนอื่นเราจะทำการทดสอบความเร็วอย่างง่าย โดยเราจะทำการทดสอบในสถานการณ์ต่อไปนี้

• มาทดสอบไฟล์สแตติกขนาดเล็ก 5 KBytes
• ไฟล์สแตติกขนาด 1MB
• การทดสอบ PHP Hello World Application อย่างง่าย
• การเปรียบเทียบระหว่าง Apache กับ NGINX สำหรับ WordPress

เราใช้ขั้นตอนเดียวกันในการทดสอบ openlitespeed กับ nginx OpenLiteSpeed ​​เป็นทางเลือกที่ยอดเยี่ยมมากสำหรับ NGINX เพราะรองรับกฎการเขียนซ้ำ . .htaccess ขั้นพื้นฐานเช่นกัน คุณจึงสามารถย้ายจาก Apache ไปเป็น OpenLiteSpeed ​​ได้อย่างง่ายดาย

มาทดสอบไฟล์สแตติกขนาดเล็ก 5 KBytes

คำตัดสินขั้นสุดท้าย : เซิร์ฟเวอร์ทั้งสองทำงานเหมือนกันกับไฟล์สแตติกขนาดเล็ก

Apache

NGINX

ไฟล์สแตติกขนาด 1MB

คำตัดสินขั้นสุดท้าย : NGINX ชนะอย่างชัดเจนด้วยไฟล์สแตติกขนาดใหญ่

Apache

NGINX

การทดสอบ PHP Hello World Application อย่างง่าย

คำตัดสินขั้นสุดท้าย : เซิร์ฟเวอร์ทั้งสองทำงานเหมือนกันกับแอปพลิเคชัน php ของ Hello world

Apache

NGINX

การเปรียบเทียบระหว่าง Apache กับ NGINX สำหรับ WordPress

คำตัดสินขั้นสุดท้าย : NGINX ชนะอย่างชัดเจนด้วยไซต์ WordPress คุณสามารถใช้คู่มือนี้เพื่อเพิ่มความเร็วให้กับร้านค้า WooCommerce ของคุณ

Apache

NGINX

ผลการทดสอบ - Apache กับ NGINX

ดังที่เราเห็นในการทดสอบว่า NGINX ค่อนข้างดีกว่า Apache ในแง่ของความเร็ว ผลลัพธ์คือ:

1. ทดสอบไฟล์สแตติกขนาดเล็ก 5 KBytes:

ในการทดสอบนี้ เราเห็นว่า Apache ad NGINX ทั้งคู่ให้ผลลัพธ์ที่เหมือนกัน

2. ทดสอบไฟล์สแตติกขนาดใหญ่ขนาด 1MB:

ในการทดสอบนี้ เราพบว่าความเร็วของ NGINX นั้นเหนือชั้นกว่า Apache NGINX ให้เวลาตอบสนองโดยเฉลี่ยน้อยกว่ามาก

3. ทดสอบ PHP Hello World Application อย่างง่าย

ในการทดสอบนี้ เราพบว่าทั้ง Apache และ NGINX ให้ผลลัพธ์ที่เหมือนกัน

4. ทดสอบ Apache กับ NGINX สำหรับ WordPress

ในการทดสอบนี้ เราพบว่าเวลาตอบสนองเฉลี่ยของ NGINX นั้นน้อยกว่า Apache มาก ทำให้มีความเร็วมากกว่า NGINX

Apache

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

สถาปัตยกรรมการจัดการการเชื่อมต่อ

Apache มีโมดูลการประมวลผลหลายตัวจำนวนมาก (เรียกว่า MPM โดย Apache) ที่ควบคุมวิธีจัดการคำขอของไคลเอ็นต์ โดยพื้นฐานแล้วสิ่งนี้ช่วยให้ผู้ดูแลระบบสามารถเปลี่ยนสถาปัตยกรรมการจัดการการเชื่อมต่อได้อย่างรวดเร็ว

• mpm-Prefor: Multi-Processing Module (MPM) นี้ใช้เว็บเซิร์ฟเวอร์ pre-forking ที่ไม่มีเธรด แต่ละกระบวนการของเซิร์ฟเวอร์สามารถตอบสนองต่อการร้องขอที่เข้ามา และขนาดของพูลเซิร์ฟเวอร์ได้รับการจัดการโดยกระบวนการหลัก เหมาะสำหรับไซต์ที่ต้องการหลีกเลี่ยงการสร้างเธรดเพื่อทำงานกับไลบรารีที่ไม่ปลอดภัยสำหรับเธรด นอกจากนี้ยังเป็น MPM ที่ดีที่สุดสำหรับการแยกแต่ละคำขอ เพื่อให้แน่ใจว่าปัญหาที่เกิดขึ้นจะไม่ส่งผลกระทบต่อผู้อื่น
• mpm-worker: เซิร์ฟเวอร์มัลติเธรดแบบมัลติโพรเซสแบบไฮบริดถูกใช้งานโดย Multi-Processing Module (MPM) สามารถให้บริการคำขอจำนวนมากโดยมีทรัพยากรระบบน้อยกว่าเซิร์ฟเวอร์ที่ใช้กระบวนการเนื่องจากใช้เธรดเพื่อส่งคำขอ ด้วยการรักษากระบวนการจำนวนมากให้พร้อมใช้งาน ซึ่งแต่ละกระบวนการมีเธรดจำนวนมาก ทำให้รักษาความเสถียรของเซิร์ฟเวอร์ที่ใช้กระบวนการไว้ได้มาก
• mpm-event: Multi-Processing Module (MPM) ของเหตุการณ์มีขึ้นเพื่อให้คำขอหลายรายการได้รับบริการพร้อมกันโดยมอบหมายการประมวลผลบางอย่างให้กับเธรดผู้ฟัง ทำให้เธรดของผู้ปฏิบัติงานว่างเพื่อให้บริการคำขอใหม่
  Apache มีการออกแบบที่ยืดหยุ่นซึ่งช่วยให้คุณเลือกจากการเชื่อมต่อที่หลากหลายและอัลกอริธึมการจัดการคำขอ เมื่อภูมิทัศน์ของอินเทอร์เน็ตเปลี่ยนไป ตัวเลือกที่นำเสนอเป็นหลักเป็นผลจากวิวัฒนาการของเซิร์ฟเวอร์และความต้องการที่เพิ่มขึ้นสำหรับการทำงานพร้อมกัน

เนื้อหาแบบคงที่และแบบไดนามิก

เซิร์ฟเวอร์ Apache สามารถจัดการเนื้อหาแบบคงที่ได้โดยใช้กลไกแบบไฟล์มาตรฐาน แนวทางของ MPM ที่กล่าวถึงข้างต้นนั้นส่วนใหญ่รับผิดชอบต่อประสิทธิภาพของขั้นตอนเหล่านี้

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

เนื่องจาก Apache สามารถจัดการเนื้อหาแบบไดนามิกภายในได้ การกำหนดค่าการประมวลผลแบบไดนามิกจึงมักจะง่ายกว่า สามารถเปลี่ยนโมดูลได้อย่างง่ายดายหากความต้องการเนื้อหาเปลี่ยนแปลง และไม่จำเป็นต้องประสานงานการสื่อสารกับซอฟต์แวร์เพิ่มเติม

การกำหนดค่าแบบกระจายเทียบกับแบบรวมศูนย์

ด้วยการวิเคราะห์และตีความคำสั่งในไฟล์ที่ซ่อนอยู่ภายในโฟลเดอร์เนื้อหา Apache ได้เพิ่มตัวเลือกเพื่ออนุญาตการกำหนดค่าเพิ่มเติมตามแต่ละไดเรกทอรี ไฟล์ . .htaccess เป็นชื่อไฟล์เหล่านี้

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

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

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

ไฟล์เทียบกับการตีความตาม URI

Apache สามารถตีความคำขอเป็นทรัพยากรระบบไฟล์จริงหรือปลายทาง URI ที่ต้องการการประเมินที่เป็นนามธรรมมากขึ้น โดยทั่วไป Apache ใช้บล็อก <Directory> หรือ <File> สำหรับบล็อกก่อนหน้า ในขณะที่บล็อก <Location> ใช้สำหรับทรัพยากรที่เป็นนามธรรมมากขึ้น

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

เมื่อคำขอไม่ตรงกับระบบไฟล์พื้นฐาน Apache เสนอตัวเลือกมากมาย ตัวอย่างเช่น คำสั่งนามแฝง สามารถใช้เพื่อแมปไปยังสถานที่อื่นได้ การใช้บล็อก <Location> แทนระบบไฟล์ทำให้คุณสามารถทำงานกับ URI ได้โดยตรง นอกจากนี้ยังมีรูปแบบนิพจน์ทั่วไปเพื่อใช้การกำหนดค่าได้อย่างยืดหยุ่นมากขึ้นทั่วทั้งระบบไฟล์

แม้ว่า Apache สามารถทำงานได้ทั้งบนระบบไฟล์พื้นฐานและพื้นที่เว็บ แต่ก็ชอบที่จะใช้เทคนิคของระบบไฟล์ การตัดสินใจออกแบบบางอย่างสะท้อนถึงสิ่งนี้ เช่น การใช้ไฟล์ of.htaccess สำหรับการตั้งค่าต่อไดเร็กทอรี

โมดูลัส

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

คุณลักษณะนี้ใช้โดย Apache สำหรับงานที่หลากหลาย เนื่องจากแพลตฟอร์มมีความสมบูรณ์ จึงมาพร้อมกับไลบรารีโมดูลขนาดใหญ่ ตัวอย่างเช่น Mod php ฝังตัวแปล PHP ลงในพนักงานที่ทำงานอยู่แต่ละคน และสามารถใช้เพื่อเปลี่ยนส่วนต่าง ๆ ของการทำงานที่สำคัญของเซิร์ฟเวอร์

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

การสนับสนุน ความเข้ากันได้ ระบบนิเวศและเอกสารประกอบ

เนื่องจาก Apache มีมานานแล้วจึงมีการสนับสนุนมากมาย สำหรับเซิร์ฟเวอร์หลักและสถานการณ์ตามงานที่เกี่ยวข้องกับการเชื่อมต่อ Apache กับซอฟต์แวร์อื่น มีไลบรารีเอกสารของบุคคลที่หนึ่งและบุคคลที่สามจำนวนมากที่สามารถเข้าถึงได้

เครื่องมือและโครงการเว็บจำนวนมากมีเครื่องมือในการบูตสแตรปตัวเองภายในสภาพแวดล้อม Apache นอกเหนือจากเอกสารประกอบ อาจมีให้ในโปรเจ็กต์เองหรือในแพ็คเกจที่ทีมบรรจุภัณฑ์ของการจัดจำหน่ายของคุณดูแล

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

ข้อดีของ Apache กับ NGINX

เว็บมาสเตอร์และนักพัฒนาหลายคนชอบ Apache มากกว่า NGINX เนื่องจากมันเก่ากว่ามาก เข้ากันได้กับระบบปฏิบัติการ Windows, Unix และ Linux

• สำหรับการเสิร์ฟวัสดุแบบไดนามิก นี่คือประสิทธิภาพที่ยอดเยี่ยม
• โหลดและยกเลิกการโหลดโมดูลแบบไดนามิก
• จัดเตรียมไฟล์ .htaccess ต่อไดเร็กทอรีที่สามารถใช้เพื่อแทนที่การตั้งค่าทั้งระบบ
• การสนับสนุนและเอกสารมีความโดดเด่น
• โมเดลนี้ใช้วิธีการเชื่อมต่อแบบครั้งเดียวต่อกระบวนการ
• ประกอบด้วยโมดูล mod_evasive และ mod_security ซึ่งเพิ่มความปลอดภัยอีกชั้นหนึ่ง

ข้อเสียของ Apache กับ NGINX

• ไม่สามารถจัดการคำขอจำนวนมากพร้อมกันได้
• เมื่อเปรียบเทียบกับ NGINX การแสดงเนื้อหาแบบคงที่จะใช้เวลานานกว่า
• ให้ความสามารถในการติดตั้งและการจัดการที่กว้างขวาง จึงไม่เหมาะกับมือใหม่
• เว็บไซต์ที่มีการเข้าชมมากมีข้อกังวลด้านประสิทธิภาพ

NGINX

ในความพยายามที่จะเอาชนะปัญหา "C10k" Igor Sysoev นักเขียนโค้ดชาวรัสเซียได้คิดค้น NGINX อิกอร์บรรลุเป้าหมาย: NGINX สามารถจัดการการเชื่อมต่อพร้อมกันมากกว่า 10,000 รายการได้อย่างง่ายดาย เพื่อจัดการกับการเชื่อมต่อใหม่ได้ดียิ่งขึ้น NGINX มีการออกแบบตามเหตุการณ์และแบบอะซิงโครนัส NGINX เป็นเว็บเซิร์ฟเวอร์ที่มีความสามารถมากมาย รายการด้านล่างเป็นบางส่วนของพวกเขา:

• แคช HTTP และตัวโหลดบาลานซ์
• พร็อกซีส่วนหน้าของ Apache และเว็บเซิร์ฟเวอร์อื่นๆ
• โปรโตคอล HTTP, HTTPS, SMTP, POP3 และ IMAP ทั้งหมดให้บริการโดยพร็อกซีเซิร์ฟเวอร์ย้อนกลับนี้

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

สถาปัตยกรรมการจัดการการเชื่อมต่อ

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

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

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

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

เนื้อหาแบบคงที่และแบบไดนามิก

NGINX ไม่มีการสนับสนุนดั้งเดิมสำหรับการประมวลผลเนื้อหาแบบไดนามิก NGINX ต้องส่ง PHP และคำขอเนื้อหาไดนามิกอื่น ๆ ไปยังโปรเซสเซอร์ภายนอกเพื่อการประมวลผล จากนั้นรอจนกว่าเนื้อหาที่แสดงผลจะถูกส่งคืน ลูกค้าสามารถแจ้งผลการวิจัยได้

สำหรับผู้ดูแลระบบ นี่หมายความว่าการสื่อสารระหว่าง NGINX และโปรเซสเซอร์ต้องได้รับการกำหนดค่าโดยใช้หนึ่งในโปรโตคอลที่ NGINX เข้าใจ (http, FastCGI, SCGI, uWSGI, memcache) การทำเช่นนี้อาจทำให้สิ่งต่างๆ ซับซ้อนขึ้นเล็กน้อย โดยเฉพาะอย่างยิ่งเมื่อประเมินจำนวนการเชื่อมต่อที่จะอนุญาต เนื่องจากการโทรไปยังโปรเซสเซอร์แต่ละครั้งจะต้องมีการเชื่อมต่อใหม่

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

การกำหนดค่าแบบกระจายเทียบกับแบบรวมศูนย์

NGINX ไม่เข้าใจไฟล์ . .htaccess และไม่มีวิธีประเมินการกำหนดค่าต่อไดเรกทอรีนอกไฟล์การกำหนดค่าหลัก แม้ว่าจะใช้งานได้หลากหลายน้อยกว่าแนวทางของ Apache แต่ก็มีประโยชน์มากมายในตัวเอง

ประสิทธิภาพที่เพิ่มขึ้นเป็นผลลัพธ์ที่เห็นได้ชัดเจนที่สุดจากวิธี . .htaccess ของการตั้งค่าระดับไดเร็กทอรี สำหรับแต่ละคำขอ เซิร์ฟเวอร์จะตรวจสอบไฟล์เหล่านี้ในแต่ละไดเร็กทอรีหลักที่นำไปสู่ไฟล์ที่ร้องขอในการตั้งค่า Apache มาตรฐานที่อนุญาต . .htaccess ในไดเร็กทอรีใดก็ได้ หากการค้นหานี้ปรากฏไฟล์ . .htaccess อย่างน้อยหนึ่งไฟล์ จะต้องอ่านและประมวลผล NGINX สามารถให้บริการคำขอได้เร็วยิ่งขึ้นโดยดำเนินการค้นหาไดเรกทอรีเดียวและอ่านไฟล์สำหรับแต่ละคำขอโดยไม่อนุญาตการแทนที่ไดเรกทอรี (สมมติว่าพบไฟล์ในโครงสร้างไดเรกทอรีทั่วไป)

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

หากคุณกังวลเกี่ยวกับปัญหาเหล่านี้ โปรดทราบว่าคุณอาจปิดใช้งานการตีความ . .htaccess ใน Apache ได้

ไฟล์ VS การตีความตาม URI

NGINX ได้รับการออกแบบมาเพื่อใช้งานเป็นเว็บเซิร์ฟเวอร์และพร็อกซีเซิร์ฟเวอร์ มันใช้งานได้กับ URI เป็นส่วนใหญ่ โดยจะแปลไปยังระบบไฟล์เมื่อจำเป็น เนื่องจากสถาปัตยกรรมที่จำเป็นสำหรับงานทั้งสองนี้

ซึ่งสามารถเห็นได้ในวิธีสร้างและประมวลผลไฟล์การกำหนดค่า NGINX ในบางกรณี
NGINX ไม่มีวิธีระบุการกำหนดค่าสำหรับไดเรกทอรีระบบไฟล์ ดังนั้นจึงแยกวิเคราะห์ URI

ตัวอย่างเช่น เซิร์ฟเวอร์และบล็อกตำแหน่ง เป็นบล็อกการกำหนดค่าที่สำคัญที่สุดสำหรับ NGINX บล็อกเซิร์ฟเวอร์มีหน้าที่ในการแปลความหมายของโฮสต์ที่ร้องขอ ในขณะที่บล็อกตำแหน่งจะรับผิดชอบส่วนที่ตรงกันของ URI หลังจากโฮสต์และพอร์ต ขณะนี้คำขอกำลังประมวลผลเป็น URI แทนที่จะเป็นตำแหน่งระบบไฟล์

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

สิ่งนี้อาจดูเหมือนคล้ายกัน แต่การตีความคำขอส่วนใหญ่เป็น URI แทนที่จะเป็นตำแหน่งระบบไฟล์ทำให้ NGINX ทำหน้าที่เป็นเว็บ เมล และพร็อกซีเซิร์ฟเวอร์ได้ง่ายขึ้น NGINX ได้รับการตั้งค่าโดยกำหนดว่าจะตอบสนองต่อรูปแบบคำขอบางรูปแบบอย่างไร NGINX จะไม่ตรวจสอบระบบไฟล์จนกว่าจะพร้อมที่จะส่งคำขอ ซึ่งเป็นสาเหตุที่ไม่รองรับไฟล์ . .htaccess

โมดูล

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

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

คุณสมบัติเดียวกันหลายอย่างมีอยู่ในโมดูล NGINX เช่นเดียวกับในโมดูล Apache ฟังก์ชันการสนับสนุนพร็อกซี การบีบอัด การจำกัดอัตรา การบันทึก การเขียนใหม่ ตำแหน่งทางภูมิศาสตร์ การตรวจสอบสิทธิ์ การเข้ารหัส การสตรีม และฟังก์ชันอีเมลทั้งหมดมีให้ใช้งานผ่านโมดูล NGINX

การสนับสนุน ความเข้ากันได้ ระบบนิเวศและเอกสารประกอบ

NGINX กำลังได้รับความนิยมเนื่องจากมีผู้ใช้มากขึ้นเนื่องจากมีประสิทธิภาพสูง แต่ก็ยังมีบางสิ่งที่ต้องทำในพื้นที่สำคัญบางอย่าง

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

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

ข้อดีของ NGINX

เว็บเซิร์ฟเวอร์ NGINX นั้นเรียบง่าย น้ำหนักเบา และรวดเร็ว ออกแบบมาโดยเฉพาะสำหรับเว็บไซต์ที่มีการเข้าชมสูง

• ใช้สถาปัตยกรรมแบบ non-blocking ที่ขับเคลื่อนด้วยเหตุการณ์ซึ่งใช้ CPU และหน่วยความจำน้อยกว่า
• ประกอบด้วยตัวเลือกการเพิ่มประสิทธิภาพและการให้บริการสำหรับเนื้อหาแบบคงที่จำนวนมาก เป็นผลให้ให้บริการเนื้อหาแบบคงที่เร็วขึ้น 2.5 เท่าและใช้หน่วยความจำน้อยกว่า Apache
• มันทำงานได้อย่างน่าชื่นชมในระบบมัลติโปรเซสเซอร์
• การโจมตี DDoS สามารถป้องกันได้ด้วยตัวเลือกการกำหนดค่าในตัว

ข้อเสียของ NGINX

• ไม่สามารถประมวลผลเนื้อหาแบบไดนามิกได้
• มีโมดูลจำนวนน้อยกว่า
• รองรับระบบปฏิบัติการ Linux และ Unix แต่การรองรับ Windows ถูกจำกัด
• ไฟล์ . .htaccess ซึ่งได้รับการสนับสนุนโดย Apache ไม่ได้รับการสนับสนุนโดย NGINX
• การขาดแคลนซอฟต์แวร์ตรวจสอบบันทึก - เพียงบันทึกบันทึกลงในไฟล์ที่ต้องสำรวจด้วยตนเอง

ในการใช้ Apache และ NGINX ร่วมกัน

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

การกำหนดค่ามาตรฐานสำหรับความร่วมมือนี้คือการใช้ NGINX เป็น reverse proxy ต่อหน้า Apache ซึ่งจะทำให้ NGINX สามารถประมวลผลคำขอของลูกค้าทั้งหมดได้ สิ่งนี้ทำให้ใช้ความเร็วในการประมวลผลที่รวดเร็วของ NGINX และความสามารถในการจัดการการเชื่อมต่อจำนวนมากในคราวเดียว

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

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

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

เมื่อใดควรใช้ Apache กับ NGINX

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

คุณสามารถใช้ Apache . ได้เมื่อใด

• หากคุณใช้แผนโฮสติ้งที่ใช้ร่วมกัน
• หากคุณชื่นชมชุมชนที่เป็นประโยชน์พร้อมทรัพยากรมากมาย ที่นี่คือที่ที่คุณควรไป
• Apache เป็นที่นิยมในหมู่นักพัฒนาเว็บเพราะติดตั้งง่าย

คุณสามารถใช้ NGINX . ได้เมื่อใด

• หากคุณมี VPS หรือเซิร์ฟเวอร์เฉพาะ
• คุณเป็นเจ้าของเว็บไซต์ยอดนิยมที่มีเนื้อหาคงที่จำนวนมาก
• หากคุณต้องการจัดการทราฟฟิกที่เข้ามาและกระจายไปยังเซิร์ฟเวอร์ต้นน้ำที่ช้ากว่า

Apache vs. NGINX: คุณควรเลือกอันไหนสำหรับเซิร์ฟเวอร์ของคุณในปี 2022

บริษัทโฮสติ้งของคุณให้บริษัทใดบริษัทหนึ่งเป็นผู้ที่คุณควรใช้ ในหลายกรณี คุณจะไม่มีตัวเลือก ผู้ให้บริการเว็บหลายรายใช้กลยุทธ์เดียวกัน ซึ่งคุณควรปฏิบัติตามหากคุณกำลังตัดสินใจระหว่าง Apache กับ NGINX:

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

เนื่องจากสถาปัตยกรรมพื้นฐานของ Apache จึงสามารถใช้ RAM ได้มากขึ้นในแง่ของประสิทธิภาพ ในกรณีที่มีการจราจรหนาแน่น NGINX จะทำงานได้ดีขึ้น โดยเฉพาะอย่างยิ่งหากมีวัสดุไฟฟ้าสถิตจำนวนมากที่ต้องจัดการ

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

บทสรุป

อย่างที่คุณเห็น Apache และ NGINX นั้นทรงพลัง ปรับเปลี่ยนได้ และมีความสามารถ การประเมินความต้องการส่วนบุคคลของคุณและการทดสอบรูปแบบที่คุณคาดว่าจะเห็นเป็นเกณฑ์หลักในการเลือกเซิร์ฟเวอร์ที่เหมาะกับคุณ

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