Comportement curieux avec le serveur http Django par défaut

Question

On m'a toujours dit que Django est un framework web synchrone, et que son serveur web par défaut est lent, non sécurisé, et le pire de tout - un thread unique. Regarder la documentation de Django sur leur implémentation d'un serveur web ne révèle pas beaucoup de détails: on me dit qu'il est "léger", et que l'équipe de Django recommande de ne pas l'utiliser en production. Une recherche sur Stackoverflow révèle que toute requête unique en suspendrait une autre jusqu'à ce que la première soit terminée - ce que vous attendez.

Mais voici le peu surprenant que j'ai rencontré en jouant avec - Si j'envoie une requête pour que le serveur dorme pendant 10 secondes (simulant des E/S de longue durée), et une autre requête simultanée pour simplement charger la page d'index , la page d'index est capable de charger immédiatement pendant que l'autre demande est traitée. Le même test, lorsqu'il est essayé sur une configuration fonctionnant derrière NGINX/Gunicorn avec un seul processus de travail Gunicorn, montre que le chargement de la page d'index est bloqué jusqu'à la fin de la première requête (sommeil pendant 10 secondes). Ce comportement est reflété dans un troisième test où Gunicorn est exécuté sans NGINX en face. C'est le comportement auquel je m'attendais - mais complètement différent du serveur par défaut!

Pourquoi cela se produit-il? Que se passe-t-il dans les coulisses avec le serveur web par défaut de Django?

Answer 1

Le serveur de développement intégré n'est pas monothread et ne l'a pas été depuis longtemps.

Sous-classes Django Python's WSGIServer, avec le ThreadingMixin. Cela engendre un nouveau thread pour chaque requête, donc une requête ne doit jamais attendre qu'un thread soit disponible. Cela ralentit la demande - chaque thread a sa propre connexion à la base de données, donc chaque nouveau thread doit ouvrir une nouvelle connexion - mais le nombre de requêtes simultanées est seulement limité par les ressources disponibles. La création de threads à la demande est pratique, mais c'est également une cible très facile pour les attaques par déni de service. C'est l'une des raisons pour lesquelles le serveur de développement est considéré comme non sécurisé, et pourquoi les serveurs WSGI prêts pour la production n'utilisent pas la même configuration.