ทำไม Nginx ถึงเร็วนัก


31

เว็บไซต์อย่างเช่น rambler ให้บริการเนื้อหาแบบไดนามิกอย่างรวดเร็วอย่างไร ยิ่งเร็วกว่า Yahoo (ซึ่งมีเซิร์ฟเวอร์ในประเทศของฉัน - SE Asia; rambler ไม่มี)

นี่คือความสามารถของ Nginx อย่างแท้จริงหรือไม่? ฉันควรจะเรียนรู้เกี่ยวกับความสามารถดังกล่าวที่ไหน

ผมเชื่อว่า serverfault.com ถ้าเสิร์ฟจาก Nginx จะเร็วขึ้นมากใน IIS 7 (สมมติว่าเวลาในการเข้าถึง db เป็นเท่าเดิมในทั้งสองกรณี) นี่เป็นข้อสมมติฐานที่ยุติธรรมหรือไม่?

แก้ไข:

โพสต์จาก Karl โดยใช้Nginx หน้า IIS7


โปรดทราบว่า serverfault.com ใช้ Nginx แล้ว (ตามWappalyzer ) : P
WillS

คำตอบ:


26

คุณอาจเห็นการนำเสนอนี้สำหรับภาพรวมของ nginx internals ความแตกต่างที่สำคัญคือการจัดการคำขอแบบอะซิงโครนัสแทนที่จะใช้เธรดเหมือนกับ Apache คุณอาจดูเอกสารนี้เช่นกัน


2
คำตอบที่ดีเกี่ยวกับสถาปัตยกรรมของ nginx และปัญหา C10K อย่างไรก็ตามฉันเข้าใจว่าคำถาม OPs นั้นเกี่ยวกับการรับรู้ความเร็วในการโหลดหน้าเว็บซึ่งไม่ค่อยเกี่ยวข้องกับ nginx
Jesper M

"อะซิงโครนัส" หมายถึงอะไรจริง ๆ ? ฉันมักจะคิดว่ามันหมายถึงการดำเนินการในหัวข้อที่แยกต่างหาก
อีวาน

ค่าเฉลี่ยแบบอะซิงโครนัส Nginx ทำหน้าที่เป็นพร็อกซีเสมอแม้กับ Php: Nginx รับคำขอ HTTP ส่งไปยังเซิร์ฟเวอร์ Php แต่ไม่ล็อค / รอเพื่อส่งการตอบกลับ HTTP นั่นเป็นเหตุผลที่คุณเห็นความแตกต่าง (ความเร็ว, CPU / RAM) สำหรับเว็บไซต์ที่มีปริมาณการใช้งานสูง แต่ไม่มีประสิทธิภาพที่เพิ่มขึ้นสำหรับการร้องขอไม่กี่อัน (ซึ่งเกี่ยวข้องกับ 95% ของอินเทอร์เน็ต .... ) แต่ Nginx นั้นเจ๋ง ;-)
Thomas Decaux

21

เว็บไซต์อย่างเช่น rambler ให้บริการเนื้อหาแบบไดนามิกอย่างรวดเร็วอย่างไร ... นี่เป็นความสามารถของ Nginx อย่างแท้จริงหรือไม่? ฉันควรจะเรียนรู้เกี่ยวกับความสามารถดังกล่าวที่ไหน

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

ส่วนที่สำคัญน้อยกว่าคือความเร็วฝั่งเซิร์ฟเวอร์คือเวลาที่ใช้ในการสร้าง HTML ส่วนที่สำคัญกว่าคือประสิทธิภาพของ 'ส่วนหน้า'ซึ่งฉันหมายถึง HTML, CSS, Javascript และรูปภาพจำนวนเหล่านี้ขนาดของสิ่งเหล่านี้และการส่งที่เหมาะสม (การบีบอัด HTTP, การแคช) ของสิ่งเหล่านี้

แน่นอนความเร็วฝั่งเซิร์ฟเวอร์ยังคงมีความสำคัญฉันไม่ได้บอกว่าควรเพิกเฉยหรือไม่สำคัญ แต่โดยทั่วไปแล้วมันเป็นส่วนที่เล็กที่สุดที่รับรู้ถึงความเร็วของผู้ใช้ - การทำงานของเซิร์ฟเวอร์มักจะทำในเวลาน้อยกว่า 500 มิลลิวินาที แต่หน้านั้นไม่พร้อมก่อน 3,000 - 5,000 มิลลิวินาทีที่ผ่านมา จำนวนมากในครั้งนี้ไปที่การดาวน์โหลดทรัพยากรส่วนหน้า (CSS, Javascript, รูปภาพ)

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

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

ฉันเชื่อว่า serverfault.com ถ้าให้บริการจาก Nginx จะเร็วกว่า IIS 7 มาก (สมมติว่าเวลาเข้าถึง db เป็นเท่ากันทั้งสองกรณี) นี่เป็นข้อสมมติฐานที่ยุติธรรมหรือไม่?

ไม่นั่นเป็นความเข้าใจผิด :-)


18

Nginx มักใช้สำหรับโหลดบาลานซ์แอปพลิเคชัน / เซิร์ฟเวอร์อื่น ๆ และให้บริการเนื้อหาแบบคงที่มากกว่าที่จะใช้เป็นเซิร์ฟเวอร์ที่สมบูรณ์

ตัวอย่างเช่นคุณอาจเขียนแอพโดยใช้หนึ่งในเฟรมเวิร์กหลามมากมายและให้ nginx เป็น front-end ไปยังอินสแตนซ์จำนวนมากของอินสแตนซ์นั้น ๆ ในกรณีนี้เซิร์ฟเวอร์ nginx มีจุดประสงค์สองประการ: มันจัดการการร้องขอเนื้อหาแบบสแตติกเช่นรูปภาพและสไตล์ชีทโดยตรง (และเนื่องจากการออกแบบมันทำได้อย่างรวดเร็วมาก ) และผ่านการร้องขอแบบไดนามิกไปยังแอปพลิเคชันที่แพร่กระจายโหลดระหว่างอินสแตนซ์ทั้งหมด . นี่เป็นโครงแบบที่นิยมมากในชุมชน Ruby on Rails ด้วย

มีเหตุผลที่เป็นไปได้อีกสองประการที่ทำให้ Rambler อาจปรากฏต่อคุณเร็วกว่าบริการ Yahoo ท้องถิ่น ประการแรก Yahoo PoP ในพื้นที่อาจไม่มีทรัพยากรเพียงพอที่จะให้บริการตามจำนวนคำขอที่ได้รับเร็วขึ้นดังนั้นอาจแค่เพิ่มฮาร์ดแวร์เพิ่มเติม (สมมติว่าซอฟต์แวร์มีขนาดเท่านี้) จะเร่งความเร็ว (แต่สันนิษฐานความแตกต่างไม่ได้ คุ้มค่ากับค่าใช้จ่ายในการบำรุงรักษาชุดอุปกรณ์เสริมหรือ Yahoo จะทำเช่นนี้) ความแตกต่างที่สำคัญอื่น ๆ อาจอยู่ในแบ็คเอนด์มากกว่าเว็บเซิร์ฟเวอร์ - บริการทั้งสองจะไม่มีข้อสงสัยใด ๆ ที่มีการจัดเรียงฐานข้อมูลที่แตกต่างกันมากและถึงแม้ว่าจะไม่ใช่พวกเขาก็ไม่น่าจะทำงานเหมือนกันทุกประการ ฮาร์ดแวร์เฉพาะสำหรับการจัดทำฐานข้อมูลจะมีผลกระทบที่สำคัญเช่นกัน)

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


3

สถาปัตยกรรมที่สามารถปรับขยายได้มากกว่า แต่ nginx ด้วยการปรับสมดุลภาระที่เหมาะสมหน้าเซิร์ฟเวอร์เนื้อหาแบบคงที่ / เครื่องกำเนิดเนื้อหาแบบไดนามิก หากคุณต้องการประสบการณ์การใช้งานที่ยอดเยี่ยมคุณควรย้ายเนื้อหาใกล้ชิดกับ 'ดวงตา' - ใช้ CDN

หากคุณสนใจในเรื่อง - ตรวจสอบนี้และที่และ .. ดี - google -]


2

ไซต์ที่ดีที่สุดใช้ตัวเร่งแอปพลิเคชันเช่น ZXTM ของ Zeus - พวกเขาสามารถแคชการตอบสนองแบบไดนามิกในหลายกรณีซึ่งเห็นได้ชัดว่ามีประโยชน์มาก



0

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.