Neugieriges Verhalten mit Standard-Django http-Server

Question

Ich habe immer gesagt, dass Django ein synchrones Web-Framework ist, und dass der Standard-Webserver langsam, unsicher und am schlechtesten ist - single threaded. Wenn man sich Djangos Dokumentation über die Implementierung eines Webservers ansieht, verrät das nicht viele Details: Mir wurde gesagt, dass es "leichtgewichtig" ist und dass das Django-Team eine Verwendung in der Produktion empfiehlt. Die Suche in Stackoverflow zeigt, dass jede einzelne Anfrage eine andere aufhängt, bis die erste abgeschlossen ist - was Sie erwarten würden.

Aber hier ist das überraschende Bit, das ich beim Herumspielen - Wenn ich eine Anfrage für den Server für 10 Sekunden (Simulation lang laufende E/A) zu senden, und eine weitere gleichzeitige Aufforderung, einfach die Indexseite laden , die Indexseite kann sofort geladen werden, während die andere Anfrage verarbeitet wird.

Der exakt gleiche Test zeigt, wenn eine NGINX/Gunicorn-Konfiguration mit einem einzelnen Gunicorn-Worker-Prozess ausgeführt wird, dass das Laden der Indexseite angehalten wird, bis die erste Anfrage (10 Sekunden lang) abgeschlossen ist. Dieses Verhalten spiegelt sich in einem dritten Test wider, bei dem Gunicorn ohne NGINX im Vordergrund läuft. Dieses Verhalten würde ich erwarten - aber völlig anders als der Standardserver!

Warum passiert das? Was passiert hinter den Kulissen mit Djangos Standard-Webserver?

Answer 1

Der integrierte Entwicklungsserver ist nicht single-threaded und war nicht für eine lange Zeit.

Django Unterklassen Python WSGIServer, zusammen mit der ThreadingMixin. Dadurch wird für jede Anforderung ein neuer Thread erstellt, sodass eine Anforderung nicht auf das Verfügbarwerden eines Threads warten muss. Dies verlangsamt die Anfrage - jeder Thread hat seine eigene Datenbankverbindung, so dass jeder neue Thread eine neue Verbindung öffnen muss - aber die Anzahl gleichzeitiger Anfragen ist nur durch die verfügbaren Ressourcen begrenzt.

Das Erstellen von Threads auf Anfrage ist praktisch, aber auch ein sehr einfaches Ziel für Denial-of-Service-Angriffe. Das ist einer der Gründe, warum der Entwicklungsserver als unsicher gilt und warum produktionsbereite WSGI-Server nicht dasselbe Setup verwenden.