Mengapa saya perlu nginx ketika saya memiliki uWSGI

62

Ada banyak tutorial tentang cara mengkonfigurasi nginx untuk bekerja sama dengan uWGSI ketika saya ingin menggunakan aplikasi Django.

Tapi mengapa saya perlu nginx dalam kit ini? uWSGI sendiri dapat melayani aplikasi WSGI Python, dapat melayani file statis, juga dapat melakukan SSL. Apa yang bisa nginx lakukan dimana uWSGI tidak bisa?

nginx django uwsgi

— pengguna983447
sumber

9

Saya dapat melihat bahwa pertanyaan ini ditutup berdasarkan opini. Saya benar-benar tidak setuju. Pertanyaan "Apa yang bisa nginx lakukan yang tidak bisa uWSGI?" berbasis fakta.

— user983447

1

Saya biasanya tidak berbicara untuk pembukaan kembali, tetapi dalam kasus ini saya setuju. Jawaban yang sudah tervotasikan dan diterima adalah yang baik, yang menunjukkan bahwa pertanyaan itu, seperti tertulis, mengakui jawaban yang masuk akal dan relevan; Saya pikir itu mungkin membuatnya menjadi pertanyaan yang bagus.

— MadHatter

55

Kamu tidak.

Itulah jawaban yang sederhana - Anda tidak membutuhkannya . uWSGI sendiri merupakan server yang mampu.

Namun, server lain seperti nginx telah ada lebih lama dan (mungkin, bagaimanapun) lebih aman, serta memiliki fitur tambahan yang tidak didukung oleh uWSGI - misalnya, peningkatan penanganan sumber daya statis (melalui kombinasi Expired atau E-Tag header, kompresi gzip, gzip pra-kompresi, dll.) yang secara signifikan dapat mengurangi beban server dan jaringan; selain itu, server seperti nginx di depan aplikasi Django Anda dapat menerapkan caching konten dinamis Anda juga, lebih lanjut membantu mengurangi beban server, dan bahkan membantu memfasilitasi penggunaan CDN (yang biasanya tidak baik dengan konten dinamis) ). Anda bahkan dapat melangkah lebih jauh dan memiliki nginx pada server yang sepenuhnya terpisah, membalikkan permintaan proxy untuk konten dinamis ke kumpulan server aplikasi yang seimbang sambil menangani konten statis itu sendiri.

Sebagai contoh, blog saya (sementara itu WordPress, memiliki nginx di depannya) disetel ke posting cache selama 24 jam, dan untuk cache halaman indeks selama 5 menit; sementara saya tidak melihat lalu lintas yang cukup untuk itu sangat penting sebagian besar waktu, itu membantu VPS kecil saya cuaca lonjakan sesekali yang mungkin menjatuhkannya - seperti lonjakan lalu lintas besar ketika salah satu artikel saya dipetik oleh seorang Twitterer dengan ribuan pengikut, banyak dari mereka men-tweetnya ke ribuan pengikut mereka.

Jika saya menjalankan server uWSGI "telanjang" (dan menganggapnya sebagai situs Django, bukan WordPress), itu mungkin akan bertahan dengan baik - atau mungkin crash dan terbakar, membuat saya kehilangan pengunjung yang terlewat . Memiliki nginx di depannya untuk menangani beban itu bisa sangat membantu.

Semua yang dikatakan, jika Anda hanya menjalankan situs kecil yang tidak akan melihat banyak lalu lintas, tidak ada kebutuhan nyata untuk nginx atau apa pun - cukup gunakan uWSGI sendiri jika itu yang ingin Anda lakukan. Di sisi lain, jika Anda akan melihat banyak lalu lintas ... yah, Anda mungkin masih menginginkan uWSGI, tetapi Anda setidaknya harus mempertimbangkan sesuatu di depannya untuk membantu memuat. Sebenarnya, Anda harus benar-benar menguji berbagai konfigurasi dengan situs Anda yang sudah selesai untuk menentukan apa yang paling sesuai untuk Anda di bawah beban yang Anda harapkan, dan menggunakan apa pun yang akhirnya menjadi.

— Kromey
sumber

3

Satu hal yang terlintas dalam benak saya yang menurut saya patut dicatat selain dari apa yang @Kromey bahas dalam jawaban mereka adalah bahwa protokol asli untuk uWSGI bukan http tetapi protokol uwsgi. Protokol uwsgi lebih sederhana dan lebih efisien untuk ditangani daripada http dan dengan demikian menempelkan server web yang lebih lengkap (nginx atau yang lainnya) di depan aplikasi uWSGI Anda sebenarnya tidak menduplikasi banyak pemrosesan dan dapat memberikan manfaat yang signifikan tergantung pada Anda kebutuhan.

— Håkan Lindqvist

@ HåkanLindqvist benar-benar benar; hanya untuk memperjelas, uWSGI sepenuhnya mampu "berbicara" HTTP, namun, jadi bisa berdiri sendiri saja, tetapi ya perlu dicatat bahwa server web di depannya akan menggunakan protokol uwsgi, bukan HTTP, untuk berbicara dengan uWSGI, dan karena itu, ya, sangat sedikit duplikasi proses yang terlibat.

— Kromey

Ini adalah jawaban yang bagus, namun, dapat ditingkatkan dengan tautan ke dokumentasi uWSGI sendiri tentang topik tersebut, yang menjelaskan dengan lebih spesifik apa yang dapat Anda lakukan dengan uWSGI: uwsgi-docs.readthedocs.io/en/latest/…

— Tobias McNulty

1

IMO, jika Anda menempatkan situs web Anda di Internet alih-alih Lab, Anda mungkin melihat perbedaannya.

Bayangkan seorang pengguna dari negara lain dengan peramban web terbuka kecepatan rendah untuk mengakses situs web Anda. uWSGI akan menangani koneksi Http itu di utas. Utas itu mungkin menghabiskan waktu cukup lama untuk menunggu permintaan Http lengkap karena kecepatan jaringan yang rendah. Jika ukuran kumpulan thread Anda adalah 100, bayangkan 100 pengguna seperti itu lambat, apa yang akan terjadi? Tidak ada utas menganggur untuk menangani permintaan Http lainnya.

Tetapi hal-hal yang sangat berbeda untuk Nginx. Nginx dirancang dalam 'Pola Reaktor'. Anda dapat google 'Pola Reaktor' untuk melihat cara kerjanya. Singkatnya, koneksi kecepatan lambat tidak mempengaruhinya untuk menangani permintaan Http lainnya.

— Ythrs
sumber

1

Saya ragu menggunakan Nginx akan mengubahnya. Ketika aplikasi Django di-host di Apache menggunakan WSGI, fungsi tampilan akan dipanggil sebelum data POST dibaca dari soket. Jadi jika klien lambat, itu akan menempati utas dari permintaan telah diterima sampai data POST telah diterima. Mengapa mengganti Apache dengan Nginx mengubahnya?

— kasperd

1

Seperti yang saya tahu, secara default, Nginx tidak akan mem-proxy permintaan HTTP ke server aplikasi backend sampai mendapatkan permintaan HTTP lengkap. Jadi untuk server aplikasi seperti Django, apa yang mereka dapatkan selalu merupakan koneksi dan permintaan HTTP yang cepat, tidak ada waktu yang terbuang untuk menunggu permintaan http lengkap, setelah menangani pencarian segera, utas yang sedang berjalan dapat menganggur untuk permintaan Http berikutnya segera.

— Jcyrss

1

Ini disebut permintaan buffering, yang diaktifkan secara default di Nginx (dalam versi Nginx yang lebih lama, tidak dimungkinkan untuk mematikan ini): nginx.org/en/docs/http/…

— Tobias McNulty