ทำไมฉันต้องมี nginx เมื่อฉันมี uWSGI

62

มีแบบฝึกหัดมากมายเกี่ยวกับวิธีกำหนดค่า nginx ให้ร่วมมือกับ uWGSI เมื่อฉันต้องการปรับใช้แอปพลิเคชัน Django

แต่ทำไมฉันต้องใช้ nginx ในชุดนี้ uWSGI ตัวเองสามารถให้บริการแอพพลิเคชั่น WSGI Python มันสามารถให้บริการไฟล์คงที่มันยังสามารถทำ SSL nginx สามารถทำอะไรได้ซึ่ง uWSGI ไม่สามารถทำได้

nginx django uwsgi

— user983447
แหล่งที่มา

9

ฉันเห็นว่าคำถามนี้ปิดตามความคิดเห็น ฉันไม่เห็นด้วยอย่างแน่นอน คำถาม "สิ่งที่ nginx ทำซึ่ง uWSGI ไม่สามารถทำได้?" ตามความเป็นจริง

— user983447

1

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

— MadHatter

55

คุณทำไม่ได้

นั่นเป็นคำตอบง่ายๆนั่นคือ - คุณไม่ต้องการมัน uWSGI เป็นเซิร์ฟเวอร์ตัวเอง

อย่างไรก็ตามเซิร์ฟเวอร์อื่น ๆ เช่น nginx นั้นใช้เวลานานกว่าและปลอดภัยกว่ารวมถึงมีฟีเจอร์เพิ่มเติมที่ uWSGI ไม่รองรับเช่นการปรับปรุงการจัดการทรัพยากรสแตติก (ผ่าน Expires หรือ E-Tag ใด ๆ ) ส่วนหัว, การบีบอัด gzip, gzip ก่อนการบีบอัด ฯลฯ ) ที่สามารถลดเซิร์ฟเวอร์และโหลดเครือข่ายได้อย่างมาก นอกจากนี้เซิร์ฟเวอร์อย่าง nginx ด้านหน้าแอ็พพลิเคชัน Django ของคุณสามารถใช้แคชเนื้อหาแบบไดนามิกของคุณได้เช่นกันช่วยลดภาระของเซิร์ฟเวอร์และช่วยในการใช้งาน CDN (ซึ่งโดยปกติแล้วจะไม่ได้ดีกับเนื้อหาแบบไดนามิก ) คุณสามารถไปต่อและมี nginx บนเซิร์ฟเวอร์ที่แยกต่างหากอย่างสมบูรณ์ย้อนกลับการร้องขอพร็อกซีสำหรับเนื้อหาแบบไดนามิกไปยังคลัสเตอร์ที่โหลดบาลานซ์ของแอ็พพลิเคชันเซิร์ฟเวอร์ในขณะที่จัดการเนื้อหาสแตติกเอง

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

ถ้าฉันใช้เซิร์ฟเวอร์ uWSGI "เปล่า" (และสมมติว่ามันเป็นไซต์ Django แทนที่จะเป็น WordPress) มันอาจยืนขึ้นได้ดี - หรืออาจจะล้มเหลวและถูกไฟไหม้ . การมี nginx อยู่ด้านหน้าเพื่อจัดการกับโหลดนั้นสามารถช่วยได้จริงๆ

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

— Kromey
แหล่งที่มา

3

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

— Håkan Lindqvist

@ HåkanLindqvistถูกต้องอย่างแน่นอน เพียงชี้แจงเท่านั้น uWSGI นั้นสามารถพูด "HTTP" ได้อย่างเต็มที่ดังนั้นสามารถยืนได้ด้วยตัวเอง แต่ก็ใช่ว่ามันคุ้มค่าที่จะสังเกตว่าเว็บเซิร์ฟเวอร์ที่อยู่ด้านหน้าจะใช้โปรโตคอล uwsgi ไม่ใช่ HTTP เพื่อ พูดคุยกับ uWSGI ดังนั้นใช่มีการทำซ้ำของการประมวลผลที่เกี่ยวข้องน้อยมาก

— Kromey

นี่คือคำตอบที่ดี แต่มันอาจจะดีขึ้นด้วยการเชื่อมโยงไปยังเอกสารเอง uWSGI ในหัวข้อซึ่งจะอธิบายกับรายละเอียดมากขึ้นสิ่งที่คุณสามารถทำอะไรกับ uWSGI: uwsgi-docs.readthedocs.io/en/latest/...

— โทเบียส McNulty

1

IMO หากคุณวางเว็บไซต์ของคุณในอินเทอร์เน็ตแทนที่จะเป็น Lab คุณอาจเห็นความแตกต่าง

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

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

— Jcyrss
แหล่งที่มา

1

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

— kasperd

1

ตามที่ฉันรู้ตามค่าเริ่มต้น Nginx จะไม่ร้องขอ HTTP proxy เพื่อแบ็กเอนด์แอพพลิเคชันเซิร์ฟเวอร์จนกว่าจะได้รับคำขอ HTTP ที่สมบูรณ์ ดังนั้นสำหรับเซิร์ฟเวอร์แอพพลิเคชั่นเช่น Django สิ่งที่พวกเขาได้รับคือการเชื่อมต่อ HTTP และคำขอที่รวดเร็วไม่มีการสูญเสียเวลารอคำขอ http ที่สมบูรณ์หลังจากจัดการเควสต์เร็ว ๆ นี้เธรดที่กำลังทำงานอาจไม่ได้ใช้งานสำหรับคำขอ Http ถัดไปเร็ว ๆ นี้

— Jcyrss

1

มันถูกเรียกว่าบัฟเฟอร์การร้องขอซึ่งเปิดใช้งานโดยค่าเริ่มต้นใน Nginx (ในรุ่นเก่าของ Nginx มันเป็นไปไม่ได้ที่จะปิดการใช้งานนี้): nginx.org/en/docs/http/ …

— Tobias McNulty