Mengapa saya perlu Nginx dan sesuatu seperti Gunicorn?


219

Saya mencari jawaban yang terlalu sederhana untuk pertanyaan berikut. Saya mencoba membangun pemahaman mendasar tentang bagaimana Nginx bekerja bersama sesuatu seperti Gunicorn.

Apakah saya memerlukan Nginx dan sesuatu seperti Gunicorn untuk menggunakan aplikasi Django di Nginx?

Jika demikian, apa yang sebenarnya menangani permintaan HTTP?

Ps. Saya tidak ingin menggunakan Apache dan mod_wsgi!


Apache dan mod_wsgi adalah cara paling sederhana untuk mengimplementasikan jembatan antara aplikasi Django Anda dan permintaan http yang juga sangat mampu di lingkungan produksi. Bagi banyak pengembang, ini berarti 'Apache lebih baik daripada nginx' jika mereka tahu, tetapi karena 'betamax lebih baik daripada VHS', sayangnya, aturan Dogma
MagicLAMP

Jawaban:


314

Terlalu disederhanakan: Anda perlu sesuatu yang mengeksekusi Python tetapi Python bukan yang terbaik dalam menangani semua jenis permintaan.

[Penafian: Saya seorang pengembang Gunicorn]

Kurang disederhanakan: Terlepas dari apa server aplikasi yang Anda gunakan (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) segala jenis penyebaran non-sepele akan memiliki sesuatu di hulu yang akan menangani permintaan yang seharusnya tidak ditangani oleh aplikasi Django Anda. Contoh sepele dari permintaan tersebut melayani aset statis (gambar / css / js).

Ini menghasilkan dua tingkatan pertama dari "arsitektur tiga tingkat" klasik. Yaitu, server web (Nginx dalam kasus Anda) akan menangani banyak permintaan untuk gambar dan sumber daya statis. Permintaan yang perlu dihasilkan secara dinamis kemudian akan diteruskan ke server aplikasi (Gunicorn dalam contoh Anda). (Sebagai tambahan, yang ketiga dari tiga tingkatan adalah basis data)

Secara historis, masing-masing tingkatan ini akan di-host di mesin yang terpisah (dan kemungkinan besar akan ada banyak mesin di dua tingkatan pertama, yaitu: 5 server web mengirimkan permintaan ke dua server aplikasi yang pada gilirannya meminta satu basis data).

Di era modern sekarang kita memiliki aplikasi dari semua bentuk dan ukuran. Tidak setiap proyek akhir pekan atau situs bisnis kecil benar-benar membutuhkan tenaga kuda dari beberapa mesin dan akan berjalan cukup bahagia dalam satu kotak. Ini telah memunculkan entri baru ke dalam array solusi hosting. Beberapa solusi akan menggabungkan server aplikasi ke server web (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, dll). Dan sama sekali tidak jarang meng-host database pada mesin yang sama dengan salah satu dari kombinasi server web / aplikasi ini.

Sekarang dalam kasus Gunicorn, kami membuat keputusan khusus (menyalin dari Ruby Unicorn) untuk menjaga hal-hal terpisah dari Nginx sambil mengandalkan perilaku proksi Nginx. Khususnya, jika kita dapat berasumsi bahwa Gunicorn tidak akan pernah membaca koneksi langsung dari internet, maka kita tidak perlu khawatir tentang klien yang lambat. Ini berarti bahwa model pemrosesan untuk Gunicorn sangat sederhana.

Pemisahan ini juga memungkinkan Gunicorn ditulis dalam Python murni yang meminimalkan biaya pengembangan sementara tidak berdampak signifikan terhadap kinerja. Ini juga memungkinkan pengguna kemampuan untuk menggunakan proxy lain (dengan asumsi mereka buffer dengan benar).

Mengenai pertanyaan kedua Anda tentang apa yang sebenarnya menangani permintaan HTTP, jawaban sederhana adalah Gunicorn. Jawaban lengkapnya adalah Nginx dan Gunicorn yang menangani permintaan tersebut. Pada dasarnya, Nginx akan menerima permintaan dan jika itu permintaan dinamis (umumnya didasarkan pada pola URL) maka itu akan memberikan permintaan itu ke Gunicorn, yang akan memprosesnya, dan kemudian mengembalikan respons ke Nginx yang kemudian meneruskan respons kembali ke aslinya klien.

Jadi sebagai penutup, ya. Anda membutuhkan Nginx dan Gunicorn (atau yang serupa) untuk penyebaran Django yang tepat. Jika Anda secara khusus ingin menjadi tuan rumah Django dengan Nginx, maka saya akan menyelidiki Gunicorn, mod_uwsgi, dan mungkin CherryPy sebagai kandidat untuk sisi Django.


14
Terima kasih telah meluangkan waktu untuk menulis jawaban yang begitu mendetail! Adakah bacaan yang disarankan untuk "arsitektur 3 tier" ini?
Saya

5
Jawaban yang bagus, namun saya tidak mengerti masalah dengan klien yang lambat.
Mads Skjern

3
@ MadsSkjern saya menebak di sini, tetapi jika Anda menganggap semua klien cepat, maka Anda dapat menggunakan kumpulan proses pekerja tetap, dan tidak perlu kode untuk kasus di mana banyak atau semua dari mereka mendapatkan diblokir menunggu klien.
Jonathan Hartley


7
aplikasi Django saya hanya melayani json, tidak ada konten statis, saya bisa pergi dengan gunicorn dan tanpa nginx
Sar009

27

Saya menyukai penjelasan ini dalam kesederhanaannya:

Nginx akan menghadapi dunia luar. Ini akan melayani file media (gambar, CSS, dll) langsung dari sistem file. Namun, itu tidak dapat berbicara langsung dengan aplikasi Django; diperlukan sesuatu yang akan menjalankan aplikasi, memberi makan permintaan dari web, dan mengembalikan respons.

Itu pekerjaan Gunicorn. Gunicorn akan membuat soket Unix, dan melayani respons terhadap nginx melalui protokol wsgi - soket meneruskan data di kedua arah:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


Itu tidak harus soket, kalau-kalau orang lain bertanya-tanya.
akshay

0

Saya mencari jawaban yang terlalu sederhana ...

Apakah saya memerlukan Nginx dan sesuatu seperti Gunicorn untuk menggunakan aplikasi Django di Nginx?

Jika demikian, apa yang sebenarnya menangani permintaan HTTP?

Jawaban yang terlalu disederhanakan:

IYA.

Baik Nginx dan Gunicorn.

Karena Anda menggunakan Nginx, tentu saja Anda membutuhkan Nginx.

Karena Anda menggunakan Django, yang merupakan kerangka kerja web, Anda memerlukan sesuatu yang menjembatani pembicaraan antara server web (Nginx) dan kerangka kerja web (Django). Dalam dunia Python, hal seperti itu disebut server WSGI (tapi anggap itu seperti perangkat tengah), contohnya termasuk Gunicorn dan uWSGI. Saat menangani permintaan, Nginx memproksi permintaan ke Gunicorn atau uWSGI, yang pada gilirannya memanggil kode Django dan mengembalikan respons.

Dokumen ini dan jawaban Paul akan membantu Anda mempelajarinya dengan lebih baik.


0

Gunicorn adalah pemborosan sumber daya. Anda dapat dengan mudah mengirimkan proxy ke Django mendengarkan pada port alih-alih menjalankan gunicorn di Django atas dan lagi nginx di atas semua itu. Dalam benchmark, saya telah melihat peningkatan kecepatan yang sangat nyata. Nginx dapat dengan mudah menangani permintaan langsung ke Django. Gunicorn tidak lain adalah flyover (sebenarnya flyover lebih lambat) di atas jalan normal. Itu hanya duduk dan makan sumber daya Anda dan mencoba untuk mengklaim menjadi kekuatan situs web Anda.

nginx pada dasarnya buffer semua permintaan dan menangani permintaan file statis dengan sendirinya (jika Anda telah mengonfigurasinya seperti itu). Dan proksi semua konten dinamis ke server lain. (Gunicorn / Django).

Gunicorn tidak memiliki kegunaan lain selain hanya mengirimkan permintaan ke aplikasi. Ini seperti sedotan yang dapat Anda minum langsung dari gelas atau minum dari sedotan dengan kecepatan terbatas (di sini orang yang minum adalah django). Dan nginx adalah pelayan yang membawakanmu segelas jus.

Saya telah membandingkan dan menemukan ini - dengan gunicorn: 22k req / s tanpa gunicorn: 34k req / s

Situs Anda akan membutuhkan req / s ekstra dalam beban berat.


1
Apakah Anda berbicara tentang menjalankan server pengembangan dalam produksi ?!
Michael Hampton

Server pengembangan dapat dijalankan di belakang server produksi (seperti nginx). Karena itu akan mendapatkan permintaan di tempat yang benar dan keamanan dan efisiensi akan ditangani oleh server produksi. Ini seperti menggunakan hanya termos WSGI +. Sebagai gantinya, Anda dapat menggunakan hanya nginx + Django (tanpa middleware memonopoli, seperti gunicorn). Silakan uji pengaturan pada beban berat dan Anda akan mengerti.
ShadowDoom

1
github.com/django/channels/issues/142 (TLDR: itu ide yang buruk)
igor
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.