UWSGI varken neden nginx'e ihtiyacım var?


62

Django uygulamasını dağıtmak istediğimde nginx'in uWGSI ile işbirliği yapacak şekilde nasıl yapılandırılacağı konusunda birçok ders var.

Peki neden bu kitte nginx'e ihtiyacım var? uWSGI, WSGI Python uygulamalarına hizmet edebilir, statik dosyalara hizmet verebilir, ayrıca SSL yapabilir. Nginx hangi uWSGI'ın yapamayacağını yapabilir?


9
Bu sorunun görüş temelli olarak kapalı olduğunu görebiliyorum. Kesinlikle katılmıyorum. "Nginx hangi uWSGI'ın yapamayacağını yapabilir?" gerçeğe dayanır.
user983447

1
Genel olarak yeniden açmalar için konuşmam ama bu durumda aynı fikirdeyim. Öngörülen ve kabul edilen mevcut cevap, iyi bir cevaptır; bu, sorunun yazıldığı gibi, mantıklı ve ilgili cevapları itiraf ettiğini; Bence bu muhtemelen iyi bir soru.
MadHatter

Yanıtlar:


55

Sen değil.

Zaten basit cevap budur - buna ihtiyacınız yok. uWSGI, yetenekli bir sunucudur.

Bununla birlikte, nginx gibi diğer sunucular daha uzun süredir ve (muhtemelen, yine de) daha güvenlidir ve uWSGI tarafından desteklenmeyen ek özelliklere sahiptir - örneğin, statik kaynakların daha iyi kullanımı (Expires veya E-Tag kombinasyonu ile) sunucu ve ağ yükünü önemli ölçüde azaltabilen başlıklar, gzip sıkıştırma, önceden sıkıştırılmış gzip vb.); Ek olarak, Django uygulamanızın önünde nginx gibi bir sunucu, dinamik içeriğinizin önbelleğe alınmasını da uygulayabilir, ayrıca sunucu yükünü azaltmaya yardımcı olur ve hatta bir CDN kullanımını kolaylaştırmaya yardımcı olur (normalde dinamik içerikle iyi sonuç vermez) ). Hatta daha da ileri gidebilir ve tamamen ayrı bir sunucuda nginx'e sahip olabilirsiniz, dinamik içeriğe yönelik proxy isteklerini tersine çevirerek statik içeriği işlerken yük dengelenmiş bir uygulama sunucuları kümesine geri döndürebilirsiniz.

Örneğin, blogum (WordPress iken, önünde nginx var) 24 saat boyunca postaları önbelleğe almak ve dizin sayfalarını 5 dakika süreyle önbelleğe almak için ayarlandı; çoğu zaman bunun için gerçekten yeterli trafik görmemekle birlikte, küçük küçük VPS'imin zaman zaman dalgalanmasına neden olabilecek, yani makalelerimden birini seçtiğimde büyük trafik dalgası gibi Binlerce takipçisine tekrar tweetleyen binlerce takipçiye sahip bir Twitter kullanıcısı tarafından büyütülmüş.

"Çıplak" bir uWSGI sunucusu çalıştırıyor olsaydım (ve WordPress yerine bir Django sitesi olduğunu varsayardım), iyi durumda olabilirdi - ya da çöktü ve yanmış olabilirdi, cevapsız ziyaretçiler bana malolmuştu. . Bu yükü taşımak için önünde nginx olması gerçekten yardımcı olabilir.

Bütün bunlar söyleniyor, sadece çok fazla trafik görmeyen küçük bir site işletiyorsanız, nginx'e veya başka bir şeye ihtiyaç duymazsınız - sadece yapmak istediğiniz şeyse uWSGI'yi kendi başınıza kullanın. Öte yandan, çok fazla trafik görüyorsanız ... peki, yine de uWSGI isteyebilirsiniz, ancak en azından yüke yardımcı olmak için önünde bir şey düşünmelisiniz. Aslında, beklenen yük altında sizin için en iyi olanı belirlemek ve bitmiş olanı kullanmak için bitmiş sitenizle gerçekten farklı yapılandırmaları test ediyor olmalısınız.


3
Aklıma gelen tek şey, cevaplarında @Kromey 'in neyin içerdiğine ek olarak dikkat çekmeye değer olduğunu düşünüyorum. Uwsgi protokolü http'den daha basit ve daha etkilidir ve bu nedenle uWSGI uygulamanızın önüne daha tam özellikli bir web sunucusu (nginx veya whatnot) yapıştırmak aslında çok fazla işlem yapmaz ve size bağlı olarak önemli avantajlar sağlayabilir. ihtiyacı vardır.
Håkan Lindqvist

@ HåkanLindqvist kesinlikle doğru; Sadece açıklığa kavuşturmak için, uWSGI tamamen HTTP "konuşma" yeteneğine sahiptir, ancak kendi başına durabilir, ancak evet, önündeki bir web sunucusunun HTTP'yi değil, uwsgi protokolünü kullanacağına dikkat çekmeye değer. uWSGI ile konuşun ve bu nedenle, evet, söz konusu işlemin çok az bir kopyası.
Kromey

Bu güzel bir cevap, ancak, ne fazla özellikleri ile açıklar konu üzerine uWSGI kendi belgelerine bir bağlantı ile geliştirilebilir olduğunu olabilir uWSGI ile yapın: uwsgi-docs.readthedocs.io/en/latest/...
Tobias McNulty

1

IMO, web sitenizi Lab yerine İnternet'e yerleştirirseniz, farkı görebilirsiniz.

Web sitenize erişmek için düşük hızlı ağ tarayıcısı olan başka bir ülkeden bir kullanıcıyı hayal edin. uWSGI, bu Http bağlantısını bir iş parçacığında ele alır. Bu iş parçacığı, düşük ağ hızı nedeniyle tam bir Http isteğini beklemek için oldukça uzun zaman alabilir. İş parçacığı havuzunuzun boyutu 100 ise, bu kadar yavaş bir şekilde 100 kullanıcı olduğunu hayal edin, ne olacak? Diğer Http isteğini işlemek için boşta iş parçacığı yok.

Ancak Nginx için işler oldukça farklı. Nginx 'Reactor Pattern' de tasarlanmıştır. Nasıl çalıştığını görmek için 'Reaktör Kalıbı' nı google'da bulabilirsiniz. Kısacası, yavaş hızlı bağlantı, diğer Http isteklerini yerine getirmek için onu etkilemez.


1
Nginx kullanmanın bunu değiştireceğinden şüpheliyim. WSGI kullanılarak Apache'de bir Django uygulaması barındırıldığında, herhangi bir POST verisi bir soketten okunmadan önce view işlevi çağrılır. Bu nedenle, müşteri yavaşsa, POST verileri alınana kadar istekten alınan bir iş parçacığını işgal eder. Neden Apache'yi Nginx ile değiştirmek bunu değiştirdi?
kasperd

1
Bildiğim kadarıyla, varsayılan olarak, Nginx, tam bir HTTP isteği alana kadar uygulama sunucusuna arka uç göndermek için HTTP isteğinde bulunmayacak. Dolayısıyla, Django gibi uygulama sunucuları için, elde ettikleri şey her zaman hızlı bir HTTP bağlantısı ve talebidir, kısa bir süre sonra tam bir http isteği beklemeye vakit kaybetmeden, kısa bir süre sonra bir sonraki Http isteği için kısa süre sonra bir sonraki Http isteği için boşta kalabilir.
Jcyrss

1
Varsayılan olarak Nginx'te etkinleştirilen istek arabelleği olarak adlandırılır ( Nginx'in
Tobias McNulty
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.