Calculer Girl
  1. Calculer Girl
  3. Le téléchargement de fichiers Django occupe-t-il le processus pendant la durée du téléchargement?
Intereting Posts
Comment comstackr un monde hello de 32 bits sur alpine? Je veux écrire des erreurs de terminal dans un fichier journal – LUMEN Pourquoi le champ st_size dans la structure est-il signé? Comment créer un alias Powershell (ou une fonction ou une applet de commande) qui s’exécute dans le même processus que mon shell? 3 tlds: forcer un seul + supprimer www avec htaccess Unix find: liste des fichiers de stdin Python + Ubuntu Linux + erreur de sauvegarde: + Exit Obtenir le nom du fichier en batch pour la boucle Envoi de données JSON volumineuses depuis l’API Web C # vers le client Javascript Comment puis-je me sortir d’un script python en toute sécurité? gVim comment définir l’atsortingbut gras guifont Comment obtenir toutes les URL possibles en utilisant .htaccess dans un seul fichier? Quelle amélioration perfromance aurai-je en passant à lighttpd d’Apache? Comment désinstaller LLVM? Pourquoi ne puis-je pas trouver cfgmgr32.lib dans le SDK Windows?

Le téléchargement de fichiers Django occupe-t-il le processus pendant la durée du téléchargement?

J’utilise Django 1.3 derrière apache via mod_wsgi (mode démon, 3 processus de travail).

Si un utilisateur télécharge un fichier, cela occupe-t-il complètement l’un des processus pendant la durée du téléchargement ou peut-il traiter d’autres demandes en attendant que des morceaux de données soient disponibles? Si 3 utilisateurs téléchargent 3 fichiers, toutes les nouvelles demandes seront-elles mises en attente jusqu’à la fin des téléchargements?

Edit : J’utilise actuellement worker mpm, 1 thread par processus démon. Je suis prêt à modifier ma configuration s’il ya une bonne raison de le faire.

Edit 2 : Idéalement, ce que je souhaiterais, c’est que Apache gère le téléchargement et le transmette à django lorsque tout le fichier a été téléchargé. Est-ce que cela se comporte par défaut, et si ce n’est pas le cas, y a-t-il une configuration que je change pour que cela se produise?

Étant donné que vous utilisez un processus de démon unique mod_wsgi, alors oui, le processus démon entier sera occupé pendant toute la durée du téléchargement. Cela est dû au fait que le contenu de la requête est diffusé directement dans l’application Django et qu’Apache ne lit pas le contenu de la requête avant que la requête ne soit transmise à mod_wsgi.

Tu as dit:

Idéalement, ce que je voudrais, c’est que Apache gère le téléchargement et le transmette à django lorsque tout le fichier a été téléchargé.

Hélas, HTTP ne fonctionne pas vraiment comme ça. Le problème est que les corps de requête http peuvent être des fichiers, ou des files d’attente de messages, ou toute autre utilisation créative pour un stream d’octets (éventuellement vide). D’une part, cela signifie que le serveur d’applications ne peut pas décider comment gérer le corps de la requête. L’application peut vouloir lire une partie de la requête et, si elle ne réussit pas (par exemple, des informations d’authentification non valides ou une raison quelconque), elle peut fermer la connexion avant qu’une bande passante ait été consacrée à la demande non valide.

Ceci est particulièrement préoccupant lorsque les requêtes peuvent être de taille arbitraire et sans limite (avec, par exemple, le codage de transfert en blocs). Le serveur d’applications peut, avec élégance, résumer le corps de la requête en un simple stream de fichiers, mais ne peut pas prendre une décision plus juste quant à son destin ultime.

Pour cette raison, les serveurs HTTP appellent normalement l’application dès que tous les en-têtes ont été lus , le corps de la demande étant prêt pour la diffusion, si l’application le souhaite.

D’un autre côté, c’est le travail des frameworks d’application de résumer les utilisations courantes, et django le fait, vous permettant de définir un répertoire de téléchargement préféré et une taille de fichier maximale, ainsi que quelques autres options. Cependant, cela rest étroitement lié aux ressortingctions imposées par les considérations de HTTP, comme mentionné ci-dessus. Cela fonctionne généralement assez bien, car la plupart des serveurs fournissent suffisamment de bande passante et de threads de travail pour toujours utiliser le matériel efficacement. Un pool de travail typique (de 5 à 50 threads / processus simultanés, par exemple), tous les téléchargements de fichiers de maintenance, ne laisse probablement pas la machine serveur avec une IO disponible pour traiter d’autres demandes.

Si votre application ne rentre pas dans ce modèle, peut-être que la plupart des requêtes sont liées au processeur, ou fonctionnent généralement dans ram, mais seules quelques requêtes effectuent des E / S disque pour le téléchargement de fichiers. Vous devrez peut-être réorganiser votre service en une structure asynchrone afin de pouvoir gérer efficacement des milliers, des centaines, des milliers de demandes simultanées mais lentes, ou simplement équilibrer différents types de requêtes sur différents serveurs d’applications. Apache est un bon serveur d’application généraliste, mais il est rarement le plus rapide pour une application spécifique.