Vraag Waarom heb ik nginx nodig als ik uWSGI heb?


Er zijn veel tutorials over hoe je nginx kunt configureren om samen te werken met uWGSI wanneer ik Django-applicaties wil inzetten.

Maar waarom heb ik nginx in deze kit nodig? uWSGI zelf kan dienen voor WSGI Python-applicaties, het kan statische bestanden dienen, het kan ook SSL doen. Wat kan nginx doen wat uWSGI niet kan?


52
2018-04-23 14:44


oorsprong


Ik kan zien dat deze vraag is gesloten als opiniërend. Ik ben het absoluut oneens. Vraag "Wat kan nginx doen, wat uWSGI niet kan?" is gebaseerd op feiten. - user983447
Ik spreek in het algemeen niet voor heropeningen, maar in dit geval ben ik het daarmee eens. Het bestaande, goedgeprezen en geaccepteerde antwoord is een goed antwoord, waaruit blijkt dat de vraag, zoals geschreven, toelaatbare en relevante antwoorden geeft; Ik denk dat dit waarschijnlijk een goede vraag is. - MadHatter


antwoorden:


Jij niet.

Dat is het simpele antwoord, hoe dan ook, jij niet nodig hebben het. uWSGI is zelf een capabele server.

Andere servers zoals nginx zijn echter al langer beschikbaar en zijn (waarschijnlijk, hoe dan ook) veiliger, evenals met extra functies die niet door uWSGI worden ondersteund - bijvoorbeeld een betere afhandeling van statische bronnen (via elke combinatie van verlopen of E-tag) headers, gzip-compressie, voorgecomprimeerde gzip, enz.) die de server- en netwerkbelasting aanzienlijk kunnen verminderen; daarnaast kan een server zoals nginx voor uw Django-applicatie ook caching van uw dynamische inhoud implementeren, verder bijdragen tot vermindering van de serverbelasting, en zelfs helpen het gebruik van een CDN te vergemakkelijken (die normaal gesproken niet goed presteren met dynamische content) ). U kunt zelfs verder gaan en nginx op een volledig aparte server plaatsen, reverse proxy-aanvragen voor dynamische inhoud omzetten naar een uitgebalanceerde cluster van toepassingsservers tijdens het verwerken van de statische inhoud zelf.

Bijvoorbeeld, mijn blog (terwijl het WordPress is, het heeft nginx ervoor) is afgestemd op cache-berichten gedurende 24 uur en om indexpagina's gedurende 5 minuten in de cache op te slaan; Hoewel ik niet genoeg verkeer zie om dat er eigenlijk echt toe doet, helpt het mijn piepkleine VPS om af en toe een piek te vertonen die het anders zou kunnen omzeilen - zoals de grote golf van verkeer toen een van mijn artikelen werd gepickt op door een Twitterer met vele duizenden volgers, van wie velen het opnieuw aan hun duizenden volgers tweeten.

Als ik een "kale" uWSGI-server had gedraaid (en ervan uitgaand dat het een Django-site was, in plaats van WordPress), had het er prima tegenop kunnen gaan - of het zou gecrasht en verbrand zijn, wat me kostte bij gemiste bezoekers . Nginx ervoor hebben om die last aan te kunnen, kan echt helpen.

Dat gezegd hebbende, als je gewoon een kleine site draait die niet veel verkeer zal zien, is er geen echte behoefte aan nginx of iets anders - gebruik gewoon uWSGI op zichzelf als dat is wat je wilt doen. Aan de andere kant, als u veel verkeer zult zien ... wel, u nog steeds misschien wilt u uSGGI, maar u moet op zijn minst iets overwegen om de lading te helpen. Eigenlijk zou u echt de verschillende configuraties van uw voltooide site moeten testen om vast te stellen wat het beste werkt voor u onder uw verwachte belasting, en alles gebruiken wat uiteindelijk zo is.


47
2018-04-23 15:25



Het enige dat in me opkomt is volgens mij het vermelden waard, naast wat @Kromey in hun antwoord heeft behandeld, is dat het native protocol voor uWSGI niet http is maar het uwsgi-protocol. Het uwsgi-protocol is eenvoudiger en efficiënter om mee om te gaan dan http en dus een meer complete webserver (nginx of wat dan ook) voor uw uWSGI-toepassing steken, dupliceert eigenlijk niet veel verwerking en biedt mogelijk aanzienlijke voordelen, afhankelijk van uw nodig heeft. - Håkan Lindqvist
@ HåkanLindqvist is absoluut correct; alleen maar om te verduidelijken, uWSGI is volledig in staat om HTTP te 'spreken', dus het kan prima op zichzelf staan, maar ja het is de moeite waard om op te merken dat een webserver ervoor het uwsgi-protocol zou gebruiken, niet HTTP, om spreek met uWSGI, en daarom, ja, heel weinig duplicatie van de verwerking. - Kromey
Dit is een goed antwoord, maar het kan worden verbeterd met een link naar de eigen documentatie van uWSGI over het onderwerp, waarin met meer bijzonderheden wordt uitgelegd wat u kan doen met uWSGI: uwsgi-docs.readthedocs.io/en/latest/... - Tobias McNulty


IMO, als je je website op internet zet in plaats van Lab, zie je misschien het verschil.

Stelt u zich eens voor dat een gebruiker uit een ander land met een open webbrowser met lage netwerksnelheid toegang heeft tot uw website. uWSGI zal die Http-verbinding in een thread afhandelen. Die thread kan behoorlijk lang duren om te wachten op een compleet Http-verzoek vanwege de lage netwerksnelheid. Als de thread-pool 100 is, stel je dan 100 gebruikers voor die zo traag zijn, wat gebeurt er dan? Geen inactieve thread om andere Http-aanvragen af ​​te handelen.

Maar dingen die heel anders zijn voor Nginx. Nginx is ontworpen in 'Reactorpatroon'. U kunt 'Reactorpatroon' googelen om te zien hoe het werkt. Kort gezegd, de langzame verbinding heeft geen invloed op andere Http-verzoeken.


1
2018-05-26 09:45



Ik betwijfel of het gebruik van Nginx dat gaat veranderen. Wanneer een Django-applicatie wordt gehost op Apache met behulp van WSGI, wordt de weergavefunctie aangeroepen voordat POST-gegevens uit een socket worden gelezen. Dus als de client traag is, zal het een thread van de aanvraag in beslag nemen totdat de POST-gegevens zijn ontvangen. Waarom zou het vervangen van Apache door Nginx dat veranderen? - kasperd
Zoals ik weet, verzendt Nginx standaard geen HTTP-verzoek naar de backend-applicatieserver totdat het een volledig HTTP-verzoek ontvangt. Dus voor applicaton-server zoals Django, wat ze hebben is altijd een snelle HTTP-connetion en -verzoek, geen tijdverspilling bij het wachten op een volledig http-verzoek, na het snel afhandelen van de quest, zou de lopende thread inactief kunnen zijn voor het volgende Http-verzoek. - jcyrss
Dit wordt request buffering genoemd, wat standaard is ingeschakeld in Nginx (in oudere versies van Nginx was het niet mogelijk om dit uit te schakelen): nginx.org/en/docs/http/... - Tobias McNulty