Question

Je suis sur le point de déployer un site de taille moyenne propulsé par Django.J'ai un serveur Ubuntu dédié.

Je ne sais vraiment pas quel logiciel serveur utiliser.Alors je me suis dit :pourquoi ne pas demander à stackoverflow.

Ce que je recherche c'est :

  • Facile à mettre en place
  • Rapide et facile sur les ressources
  • Peut servir des fichiers multimédias
  • Capable de servir plusieurs djangosites sur le même serveur
  • Je préfère ne pas installer PHP ou quoi que ce soit d'autre qui consomme des ressources et dont je n'ai aucune utilité.

J'ai entendu parler de mod_wsgi et mod_python sur Apache, nginx et lighty.Quels sont les avantages et les inconvénients de ces solutions et ai-je raté quelqu'un ?

@Barry:D'une manière ou d'une autre, j'ai l'impression qu'Apache est trop gonflé pour moi.Et les alternatives ?

@BrianLy:Ok, je vais vérifier un peu plus mod_wsgi.Mais pourquoi ai-je besoin d'Apache si je sers des fichiers statiques avec Lighty ?J'ai également réussi à servir l'application Django elle-même avec Lighty.Est-ce que c'est mauvais de toute façon ?Désolé d'être si stupide :-)

MISE À JOUR:Qu'en est-il de Lighty et de Nginx ? Quels sont les cas d'utilisation où ils constituent le choix parfait ?

Était-ce utile?

La solution

Comme je cherchais des réponses plus approfondies, j'ai décidé de rechercher moi-même la question en profondeur.S'il vous plaît laissez-moi savoir si j'ai mal compris quelque chose.

Certaines recommandations générales consistent à utiliser un serveur Web distinct pour gérer les médias.Par séparé, j'entends un serveur Web qui n'exécute pas Django.Ce serveur peut être par exemple :

  • Lighttpd (Léger)
  • Nginx (EngineX)
  • Ou un autre serveur léger

Ensuite, pour Django, vous pouvez emprunter différentes voies.Tu peux soit:

  • Servir Django via Apache et:

    • mod_python

      C'est la méthode stable et recommandée/bien documentée.Les inconvénients:utilise beaucoup de mémoire.

    • mod_wsgi

      D'après ce que j'ai compris, mod_wsgi est une alternative plus récente.Cela semble être plus rapide et plus économe en ressources.

    • mod_fastcgi

      Lorsque vous utilisez FastCGI, vous déléguez le service de Django à un autre processus.Puisque mod_python inclut un interpréteur python dans chaque requête, il utilise beaucoup de mémoire.C'est une façon de contourner ce problème.Il existe également quelques problèmes de sécurité.

      Ce que vous faites, c'est démarrer votre serveur Django FastCGI dans un processus séparé, puis configurer Apache via des réécritures pour appeler ce processus en cas de besoin.

Ou tu peux:

  • Servir Django sans utiliser Apache mais avec un autre serveur qui supporte nativement FastCGI :

    (La documentation mentionne que vous pouvez le faire si vous n'avez pas de besoins spécifiques à Apache.Je suppose que la raison doit être d'économiser de la mémoire.)

    • Lumièretpd

    C'est le serveur qui exécute Youtube.Il semble rapide et facile à utiliser, mais j'ai vu des rapports sur des fuites de mémoire.

    • nginx

    J'ai vu des benchmarks affirmant que ce serveur est encore plus rapide que lighttpd.Cependant, c'est principalement documenté en russe.

Une autre chose, en raison des limitations de Python, votre serveur doit fonctionner en mode forké et non en mode threadé.

C'est donc ma recherche actuelle, mais je veux plus d'opinions et d'expériences.

Autres conseils

j'utilise Cherokee.

Selon leurs repères (grain de sel avec eux), il gère mieux la charge que Lighttpd et nginx...Mais ce n'est pas pour ça que je l'utilise.

Je l'utilise parce que si tu tapes cherokee-admin, il démarre un nouveau serveur auquel vous pouvez vous connecter (avec un mot de passe à usage unique) et configurer l'ensemble du serveur via un webmin magnifiquement réalisé.C'est une fonctionnalité qui tue.Cela m'a déjà épargné un parcelle de temps.Et cela économise beaucoup de ressources sur mon serveur !

Quant à Django, je l'exécute en tant que processus SCGI threadé.Fonctionne bien.Cherokee peut aussi le faire fonctionner.Encore une fois, une fonctionnalité très intéressante.

La version actuelle du dépôt Ubuntu est très ancienne, je vous conseille donc d'utiliser leur PPA.Bonne chance.

Comme @Barry l'a dit, la documentation utilise mod_python.Je n'ai pas utilisé Ubuntu comme serveur, mais j'ai eu une bonne expérience avec mod_wsgi sur Solaris.Vous pouvez trouver de la documentation pour mod_wsgi et Django sur le mod_wsgi site.

Un aperçu rapide de vos besoins :

  • Facile à installer J'ai trouvé Apache 2.2 assez facile à construire et à installer.
  • Rapide et facile sur les ressources Je dirais que cela dépend de votre utilisation et de votre trafic.* Vous ne souhaiterez peut-être pas serveur tous les fichiers à l'aide d'Apache et utiliser LumièreTPD (léger) vers les fichiers statiques du serveur.
  • Peut servir des fichiers multimédias Je suppose que vous voulez dire des images, des fichiers flash ?Apache peut le faire.
  • Plusieurs sites sur le même serveur Hébergement de serveur virtuel sur Apache.
  • Plutôt ne pas installer d'autres extensions Commentez tout ce que vous ne voulez pas dans la configuration Apache.

La méthode officiellement recommandée pour déployer un projet Django est d'utiliser mod_python avec Apache.Ceci est décrit dans La documentation. Le principal avantage de ceci est qu’il s’agit du moyen de déploiement le mieux documenté, le plus pris en charge et le plus courant.L'inconvénient est que ce n'est probablement pas le plus rapide.

La meilleure configuration n'est pas si connue je pense.Mais voici :

  1. Utilisez nginx pour répondre aux requêtes (dynamique vers l'application, contenu statique directement).
  2. Utilisez le serveur Web Python pour diffuser du contenu dynamique.

Les deux solutions les plus rapides pour un serveur Web basé sur Python sont :

Vous devez consulter Google pour trouver la meilleure configuration actuelle pour Django (toujours en développement).

J'utilise nginx (0.6.32 tiré de Sid) avec mod_wsgi.Cela fonctionne très bien, même si je ne peux pas dire si c’est mieux que les alternatives car je n’en ai jamais essayé.Nginx a memcaché support intégré, qui peut peut-être interagir avec le middleware de mise en cache de Django (je ne l'utilise pas réellement, à la place je remplis le cache manuellement à l'aide de python-memcache et je l'invalide lorsque des modifications sont apportées), donc les hits de cache contournent complètement Django (mon développement la machine peut traiter environ 3 000 requêtes par seconde).

Une mise en garde :nginx' mod_wsgi n'aime pas du tout les emplacements nommés (il essaie de les transmettre SCRIPT_NAME), donc l’évidence ‘error_page 404 = @django» provoquera de nombreuses erreurs obscures.J'ai dû patcher la source mod_wsgi pour résoudre ce problème.

J'ai également du mal à comprendre toutes les options.Dans ce billet de blog J'ai trouvé certains avantages de mod_wsgi par rapport à mod_python expliqués.

Plusieurs sites à faible trafic sur un petit VPS font de la consommation de RAM la principale préoccupation, et mod_python semble y être une mauvaise option.En utilisant lighttpd et FastCGI, j'ai réussi à réduire l'utilisation minimale de la mémoire d'un simple site Django à 58 Mo virtuels et 6,5 Mo résidents (après avoir redémarré et répondu à une seule requête non gourmande en RAM).

J'ai remarqué que la mise à niveau de Python 2.4 vers 2.5 sur Debian Etch augmentait de quelques pour cent l'empreinte mémoire minimale des processus Python.D'un autre côté, la meilleure gestion de la mémoire de la version 2.5 pourrait avoir un effet inverse plus important sur les processus de longue durée.

Rester simple: Django recommande Apache et mod_wsgi (ou mod_python).Si la diffusion de fichiers multimédias constitue une partie très importante de votre service, pensez à Amazon S3 ou Rackspace CloudFiles.

À mon avis, la pile la meilleure/la plus rapide est vernis-nginx-uwsgi-django.Et je l'utilise avec succès.

Si vous utilisez lighthttpd, vous pouvez également utiliser FastCGI pour servir Django.Je ne sais pas comment la vitesse se compare à mod_wsgi, mais si la mémoire est bonne, vous bénéficiez de quelques avantages que vous obtiendriez avec mod_wsgi et que vous n'obtiendriez pas avec mod_python.Le principal étant que vous pouvez donner à chaque application son propre processus (ce qui est très utile pour garder la mémoire des différentes applications séparée ainsi que pour tirer parti des ordinateurs multicœurs.

Modifier:Juste pour ajouter concernant votre mise à jour sur nginix, si la mémoire est à nouveau correcte, nginix utilise des "greenlets" pour gérer la concurrence.Cela signifie que vous devrez peut-être être un peu plus prudent pour vous assurer qu'une application ne consomme pas tout le temps du serveur.

Nous utilisons nginx et FastCGI pour tous nos déploiements Django.C'est principalement parce que nous déployons habituellement chez Slicehost et que nous ne voulons pas donner toute notre mémoire à Apache.Je suppose que ce serait notre "cas d'utilisation".

Quant aux remarques sur la documentation principalement en russe, j'ai trouvé la plupart des informations sur le wiki anglais être très utile et précis.Ce site propose également des exemples de configurations pour Django, à partir desquels vous pouvez modifier votre propre configuration nginx.

Il existe de nombreuses façons de procéder. Pour cette raison, je vous recommande de lire attentivement l'article relatif au processus de déploiement sur DjangoAdvent.com :Eric Florenzano - Déployer Django avec FastCGI : http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/ A lire aussi :Mike Malone - Blog Django Stochasticchnologies Django:Le blog parfait de la configuration de Django Mikkel Hoegh:35 % Amélioration du temps de réponse-switching-uwsgi-nginx

Salutations

J'ai un avertissement concernant l'utilisation de Cherokee.Lorsque vous apportez des modifications à Django Cherokee, il conserve l'ANCIEN processus, au lieu de le supprimer et d'en démarrer un nouveau.

Sur Apache, je recommande fortement cet article.

http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl

Il est facile à configurer, facile à supprimer ou à réinitialiser après avoir apporté des modifications.

Tapez simplement dans le terminal

sudo /etc/init.d/apache2 restart

et les changements sont visibles instantanément.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top