Le livre de

Configuration de base

Pour configurer Django avec mod_python, assurez d’abord qu’Apache soit installé et que le module mod_python soit activé. Cela signifie habituellement que la directive LoadModule est présente dans votre fichier de configuration d’Apache. Il devrait ressembler à ceci:

LoadModule python_module /usr/lib/apache2/modules/mod_python.so

Ensuite, éditez votre fichier de configuration Apache et ajoutez les lignes suivantes:

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

Assurez vous de remplacer mysite.settings avec le DJANGO_SETTINGS_MODULE approprié à votre site.

Ceci indique à Apache qu’il lui faut «utiliser mod_python pour tout URL à la racine “/” et en dessous, grâce au gestionnaire mod_python». La valeur de DJANGO_SETTINGS_MODULE est transmise de façon à ce que mod_python sache quel est le paramètre à utiliser.

Notez que nous utilisons la directive <Location>, et non pas <Directory>. Cette dernière est utilisée pour pointer les emplacements de votre système de fichier, alors que <Location> pointe les emplacements dans la structure de l’URL d’un site web. <Directory> n’aurait pas de sens ici.

Apache tourne probablement sous un utilisateur différent que celui sous lequel vous êtes connecté et peut présenter des chemins systèmes différents. Vous aurez peut être à indiquer à mod_python comment trouver votre projet et où trouver Django.

PythonPath "['/path/to/project', '/path/to/django'] + sys.path"

Vous pouvez aussi ajouter des directives telles que PythonAutoReload Off pour des raisons de performance. Consultez la documentation sur mod_python pour une liste complète des options.

Notez que vous devez placer PythonDebug Off sur un serveur de production. Si vous laissez PythonDebug On, vos utilisateurs verrons les rapports d’erreur de Python (pas très jolis et révélateurs) si quelque chose se passe mal avec mod_python.

Redémarrez Apache, et toute requête vers votre site (ou votre hôte virtuel si vous avez placez cette directive dans un bloc <VirtualHost>) sera servi par Django.

<Location "/mysite/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

urlpatterns = patterns('',
    (r'^mysite/', include('normal.root.urls')),
)

Faire tourner de multiples installations Django avec la même instance d’Apache

Il est tout à fait possible de faire tourner de multiples installations de Django sur la même instance Apache. Vous pourriez vouloir faire ceci si vous êtes un développeur web indépendant avec de multiples clients mais un unique serveur.

Pour faire cela, utilisez simplement VirtualHost comme ceci:

NameVirtualHost *

<VirtualHost *>
    ServerName www.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</VirtualHost>

<VirtualHost *>
    ServerName www2.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
</VirtualHost>

Si vous devez placer deux installations Django dans le même VirtualHost, vous devrez prendre des précautions particulières pour vous assurez que le code du cache mod_python ne bouscule pas les choses. Utilisez la directive PythonInterpreter pour donner aux diverses directives <Location> des interpreteurs séparé:

<VirtualHost *>
    ServerName www.example.com
    # ...
    <Location "/something">
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonInterpreter mysite
    </Location>

    <Location "/otherthing">
        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
        PythonInterpreter mysite_other
    </Location>
</VirtualHost>

Les valeurs de PythonInterpreter n’importe par réellement, dès lors qu’elles sont différentes sur les deux blocs Location.

Lancer un serveur de développement avec mod_python

Parce que les caches mod_python charges du code Python, lorsque vuos déployez des sites Django avec mod_python vous devrez redémarrer Apache à chaque fois que vous apportez des modifications à votre code. Ceci pouvant être laborieux, voici une petite astuce pour éviter cela; ajoutez simplement MaxRequestsPerChild 1 à votre fichier de configuration pour obliger Apache à tout recharger à chaque requête. Ne faîtes pas cela sur un serveur de production, ou nous vous retirerons vos privilèges Django.

Si vous êtes le genre de programmeur qui débug en utilisant des instructions print de-ci de-là (nous en sommes), notez que les instructions print n’ont pas d’effet avec mod_python; elles n’apparaissent dans les logs d’Apache, comme vous pourriez l’attendre. Si vous avez besoin d’afficher des informations de débugage dans une configuration utilisant mod_python, vous utiliserez probablement le module de connection Python standard. Plus d’informations sont disponibles à l’adresse http://docs.python.org/lib/module-logging.html. Alternativement, vous pouvez ajouter les informations de débugage au gabarit de votre page.

Servir des fichiers médias depuis une instance Apache

Django ne doit pas être utilisé pour fournir directement des fichiers médias; laissez ce travail à n’importe quel serveur que vous choisirez. Nous vous recommandons d’utiliser un serveur web séparé (c’est à dire, un serveur où Django ne tourne pas déjà) pour fournir des médias. Pour plus d’informations, lisez la section «Monter en charge».

Si, toutefois, vous n’avez pas d’autre options que de servir des fichiers médias depuis le même VirtualHost Apache que Django, voici comment vous pouvez désactiver mod_python pour une région particulière du site:

<Location "/media/">
    SetHandler None
</Location>

En ajustant Location à l’URL racine de vos fichiers média.

Vous pouvez aussi utiliser <LocationMatch> pour la correspondance avec une expression régulière. Par exemple, ceci place Django à la racine du site mais désactive explicitement Django pour le sous répertoire media et pour toutes les URLs se terminant par .jpg, .gif, ou .png:

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>

<Location "/media/">
    SetHandler None
</Location>

<LocationMatch "\.(jpg|gif|png)$">
    SetHandler None
</LocationMatch>

Pour tous ces cas, vous devrez placer la directive DocumentRoot de façon à ce qu’Apache sache où trouver vos fichiers statiques.

Gestion des erreurs

Lorsque vous utilisez Apache/mod_python, les erreurs seront captées par Django - en d’autres termes, elles ne se propagerons pas au niveau d’Apache et n’apparaitrons pas dans le fichier error_log d’Apache.

L’exception à cela se produit si quelque chose est vraiment incohérent dans votre configuration de Django. Dans ce cas, vous verrez une page «Internal Server Error» dans votre navigateur et l’intégralité du rapport Python dans votre fichier Apache error_log. La trace error_log est répartie sur plusieurs ligne (oui, c’est sale et plutot difficile à lire, mais c’est ainsi que mod_python fait les choses).

Gérer une erreur de segmentation

Parfois, Apache fait une erreur de segmentation lors de l’installation de Django. Lorsque ceci arrive, c’est presque toujours le fait d’une des deux causes, sans liens avec Django lui même:

• il se peut que votre code Python importe le module pyexpat (utilisé pour parcourir du XML), ce qui peut entrer en conflit avec la version embarquée dans Apache. Pour des informations complètes, lisez «Expat Causing Apache Crash» à l’adresse http://www.djangoproject.com/r/articles/expat-apache-crash/.
• il est possible que vous fassiez tourner mod_python et _mod_php dans la même instance Apache, avec MySQL pour moteur de base de données. Dans certains cas, ceci génère un problème connu sous mod_python, problème lié à un conflit de version entre le moteur MySQL de PHP et de Python. Des informations complètes se trouvent dans une entrée de la FAQ mod_python, accessible à l’adresse http://www.djangoproject.com/r/articles/php-modpython-faq/.

Si vous continuez à avoir des problèmes lors du paramètrage de mod_python, une bonne chose à faire est de récupérer un site fonctionnant uniquement avec mod_python, sans le framework Django. C’est une façon simple d’isoler les problèmes spécifiques à mod_python. L’article «Getting mod_python Working» détaille cette procédure: http://www.djangoproject.com/r/articles/getting-modpython-working/.

l’étape suivante est l’édition de votre code de test et l’ajout d’un import de tout le code spécifique à Django que vous utilisez - vos vues, vos modèles, vos URLconfs; la configuration de votre RSS, et ainsi de suite. Placez ces imports dans votre gestionnaire de test et testez l’acces aux URL dans un navigateur. Si cela cause un crash, vous avez confirmez qu’il s’agit bien de l’importation de code Django qui pause problème. En réduisant graduellement le jeu d’imports jusqu’à ce que le crash n’est plus lieu, vous trouverez le module spécifique qui cause le problème. explorez alors ces modules et consultez aussi ce qu’ils importent si nécessaire. Pour plus d’aide sur le sujet, des outils comme ldconfig sous Linux, otool sous Mac OS, et ListDLLs (de SysInternals) sous Windows peuvent vous aider à identifier des dépendances partagées et de possibles conflits de versions.

Tour d’horizon de FastCGI

FastCGI est un moyen efficace de permettre à une application externe de servir des pages à un serveur web. Le serveur Web délègue les requêtes web entrantes (via un socket) à FastCGI, qui exécute le code et transmet la réponse au serveur web, qui à son tout, la renvoie au navigateur web du client.

Tout comme mod_python, FastCGI autorise le code à rester en mémoire, permettant ainsi aux requêtes d’être servi sans délai. À la différence de mod_python, un processus FastCGI ne tourne pas dans un processus du serveur web, mais dans un processus séparé, persistant.

Traditionnelement, mod_* d’Apache embarque divers langages de scripts (plus particulièrement PHP, Python/mod_python, et Perl/mod_perl) au sein de l’espace processus de votre serveur web. Même si cela diminue le temps de démarrage (puisque le code n’a aps a être lu depuis le disque à chaque requête), c’est au prix de l’utilisation de la mémoire.

Chaque processus Apache récupère une copie du moteur Apache, complétée par toutes les fonctionnalités d’Apache dont Django ne tire tout simplement pas partie. Les processus FasctCGI, d’un autre côté, n’ont que la surchage mémoire liée à Python et Django.

Du fait de la nature de FastCGI, il est aussi possible d’avoir des processus qui tournent sous un compte utilisateur différent du processus appartenant au serveur web. C’est un apport sympathique à la sécurité des systèmes distribués, parce que cela signifie que vous pouvez sécuriser votre code vis à vis des autres utilisateurs.

Avant que vous ne commencier à utiliser FastCGI avec Django, vous devrez installer flup, une bibliothèque Python pour gérer FastCGI; Certains utilisateurs ont rapportés des pages manquantes avec les anciennes versions de flup, vous préférerez probablement utiliser la dernière version SVN. flup est disponible à l’adresse http://www.djangoproject.com/r/flup/.

Lancer votre serveur FastCGI

FastCGI utilise un modèle client/serveur, aussi dans la plupart des cas vous démarrerez le processus FastCGI serveur par vous même. Votre serveur web (qu’il s’agisse d’Apache, lighttpd, ou autre) contacte votre processus Django-FastCGI uniquement lorsque le serveur à besoin de charger une page web dynamique. Puisque le démon est déjà fonctionnel avec le code en mémoire, il est capable de fournir la réponse très rapidement.

./manage.py runfcgi [options]

kill `cat $PIDFILE`

#!/bin/bash

# Replace these three settings.
PROJDIR="/home/user/myproject"
PIDFILE="$PROJDIR/mysite.pid"
SOCKET="$PROJDIR/mysite.sock"

cd $PROJDIR
if [ -f $PIDFILE ]; then
    kill `cat -- $PIDFILE`
    rm -f -- $PIDFILE
fi

exec /usr/bin/env - \
  PYTHONPATH="../python:.." \
  ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

Utiliser Django avec Apache et FastCGI

Pour utiliser Django avec Apache et FastCGI, vous aurez besoin d’installer et de configurer Apache, avec mod_fastcgi d’installé et de configuré. Consultez la documentation d’Apache et de mod_fastcgi pour les instructions: http://www.djangoproject.com/r/mod_fastcgi/.

Lorsque vous avez complétez le paramètrage, pointez Apache sur votre instance Django FastCGI en éditant le fichier httpd.conf (configuration d’Apache). Vous aurez besoin de faire deux choses:

• Utilisez la directive FastCGIExternalServer pour préciser l’emplacement de votre server FastCGI.
• Utilisez mod_rewrite pour pointer les URLs sur le FastCGI approprié.

# Connect to FastCGI via a socket/named pipe:
FastCGIExternalServer /home/user/public_html/mysite.fcgi -socket
/home/user/mysite.sock

# Connect to FastCGI via a TCP host/port:
FastCGIExternalServer /home/user/public_html/mysite.fcgi -host
127.0.0.1:3033

<VirtualHost 12.34.56.78>
  ServerName example.com
  DocumentRoot /home/user/public_html
  Alias /media /home/user/python/django/contrib/admin/media
  RewriteEngine On
  RewriteRule ^/(media.*)$ /$1 [QSA,L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]
</VirtualHost>

FastCGI et lighttpd

lighttpd (http://www.djangoproject.com/r/lighttpd/) est un serveur web léger couramment utilisé pour servir des fichiers statiques. Il supporte le fastCGI nativement et c’est aussi un choix idéal pour servir à la fois des fichiers statiques et des pages dynamiques, si votre site n’a pas de besoins spécifiques à Apache.

Assurez-vous que mod_fastcgi est dans votre liste de modules, quelque part après mod_rewrite et mod_access, mais pas après mod_accesslog. Vous voudrez aussi probablement mod_alias, pour servir les médias d’admin.

Ajoutez ce qui suit à votre fichier de configuration lighttpd:

server.document-root = "/home/user/public_html"
fastcgi.server = (
    "/mysite.fcgi" => (
        "main" => (
            # Use host / port instead of socket for TCP
            fastcgi
            # "host" => "127.0.0.1",
            # "port" => 3033,
            "socket" => "/home/user/mysite.sock",
            "check-local" => "disable",
        )
    ),
)
alias.url = (
    "/media/" => "/home/user/django/contrib/admin/media/",
)

url.rewrite-once = (
    "^(/media.*)$" => "$1",
    "^/favicon\.ico$" => "/media/favicon.ico",
    "^(/.*)$" => "/mysite.fcgi$1",
)

# If the hostname is 'www.example1.com'...
$HTTP["host"] == "www.example1.com" {
    server.document-root = "/foo/site1"
    fastcgi.server = (
       ...
    )
    ...
}

# If the hostname is 'www.example2.com'...
$HTTP["host"] == "www.example2.com" {
    server.document-root = "/foo/site2"
    fastcgi.server = (
       ...
    )
    ...
}

Utiliser Django avec Apache sur un serveur mutualisé

Beaucoup d’hébergeurs de serveurs mutualisés n’autorisent pas à faire tourner votre propre démon serveur ou à éditer le fichier httpd.conf. Dans ce cas, il est toujours possible de faire tourner Django en utilisant les processus engendrés par le serveur web.

AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]

#!/usr/bin/python
import sys, os

# Add a custom Python path.
sys.path.insert(0, "/home/user/python")

# Switch to the directory of your project. (Optional.)
# os.chdir("/home/user/myproject")

# Set the DJANGO_SETTINGS_MODULE environment variable.
os.environ['DJANGO_SETTINGS_MODULE'] = "myproject.settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")

touch mysite.fcgi

Fonctionnement avec un unique serveur

La plupart des sites débutent sur une seule machine, avec une architecture qui ressemble à quelque chose comme la Figure 20-1.

Figure 20-1: configuration d’un serveur Django unique.

Ceci fonctionne parfaitement pour les sites de petite à moyenne taille, et reste relativement bon marché - vous pouvez avoir un site Django basé sur un seul serveur pour moin de 3000€.

Cependant, lorsque le traffic augmente, vous serez rapidement confronté à des problème d’allocation de ressources entre les différentes parties du logiciel. Les serveurs de base de données et les serveurs web adorent avoir tout le serveur à leur disposition, et donc lorsqu’ils tournent sur la même machine ils finissent souvent par se battre pour obtenir les mêmes ressources (RAM, CPU) qu’ils préféreraient monopoliser.

Ceci est aisément résolu en déplaçant le serveur de base de données sur une seconde machine, comme expliqué dans la section suivante.

Dissocier le serveur de base de données

En ce qui concerne Django, le fait de séparer le serveur de base de données est extremement simple: vous aurez juste à changer le paramètre DATABASE_HOST au profit de l’IP ou du DNS de votre serveur de base de données. Il est judicieux d’utiliser plutôt l’IP si cela est possible, puisque compter sur le DNS pour la connection entre votre serveru web et le serveur de base de données n’est pas recommandé.

Avec une serveur de base de données séparé, notre architecture ressemble à présent à la Figure 20-2.

Figure 20-2: Déplacer la base de données sur un serveur qui lui est dédié.

Ici nous allons commencer à travailler sur ce que l’on appelle couramment une architecture n-tiers. Ne soyez pas impressioné par ce mot à la mode - il fait simplement référence au fait que des «tiers» différent de la pile web sont séparés sur des machines physiquement dissociées.

À ce stade, si jamais vous prensez avoir besoin de vous étendre au-delà d’un seul serveur de base de données, c’est probablement une bonne idée de commencer à penser aux groupements de connexion ou à la réplication de bases de données. Malheureusement, ce livre n’ayant pas suffisament de place pour rendre justice à ces sujets, vous devrez consulter la documentation de votre base de données et votre communauté pour plus d’information.

Utliser un serveur de media dissocié

Nous avons toujours un gros problème laissé par le paramètrage en serveur unique: le service des médias depuis la même machine que celle qui gère le contenu dynamique. Ces deux activités sont optimales selon des circonstances différentes, et lorsqu’elles entre en collision sur la même machine vous n’arriverez jamais à obtenir de bonne performances. L’étape suivante est donc de séparer les médias - c’est à dire tout ce qui n’est pas généré par une vue Django - sur un serveur dédié à cela (voir la Figure 20-3).

Figure 20-3: Séparer le serveur de média.

Idéalement, ce serveur de médias doit tourner sur un serveur simplifié et optimisé pour le service des médias statiques. lighttpd et tux (http://www.djangoproject.com/r/tux/) sont tous deux d’excellents choix, mais des serveurs Apaches lourdement simplifié font aussi l’affaire.

Pour les sites ayant du contenu statique lourd (photos, videos, etc.), dissocié le serveur de media est doublement important et doit presqu’être la première étape de la montée en charge.

Cette étape peut être toutefois un peu laborieuse. Les administrateur Django doivent être capable d’ajouter des médias sur le serveur de médias (le paramètre MEDIA_ROOT contrôle l’emplacement de cette ajout). Si les médias résident sur un autre serveur, vous devrez quoi qu’il en soit trouver une façon pour que cette écriture se fasse au travers du réseau.

La manière la plus simple de faire ceci est d’utiliser NFS pour monter le répertoire médias du serveur de médias sur le(s) serveur(s) web. Si vous les montez au même endroit que celui pointé par MEDIA_ROOT, le téléchargement de média fonctionnera directement.

Implémenter la répartition de charge et la redondance

À ce stade, nous avons éclater les choses autant que possible. Cette configuration à trois serveurs doit pouvoir gérer une grosse quantité de traffic - nous avons fournis près de 10 millions de connexions par jour avec une architecture de la sorte - aussi si vous continuez à grandir, vous devrez commencer à ajouter de la redondance.

C’est une bonne chose à vrai dire. Un coup d’oeil à la Figure 20-3 vous indique que si même un seul de vos trois serveurs faillit, vous plantez intégralement votre site. Vous devez donc ajouter des serveurs redondant, pas seulement pour augmenter votre capacité, mais aussi pour augmenté la fiabilité.

Pour prendre cette exemple, considérons que le serveur web atteigne ses limites en premier. Il est facile d’avoir de multiples copies d’un site Django tournant sur du matériel différent - copiez simplement tout le code sur de multiples machines, et démarrez Apache sur les deux.

Cependant, vous aurez besoin d’une autre pièce matérielle pour répartir le trafic sur de multiple serveurs: un load balancer (répartiteur de charge). Vous pouvez achetez des répartiteurs de charge honéreux et propriétaires, mais il existe quelques répartiteurs de charge logiciels open-source de grande qualité.

Le mod_proxy d’Apache est une option, mais nous avons rencontrez Perlbal (http://www.djangoproject.com/r/perlbal/) tout simplement fantastic. C’est un répartiteur de charge et un reverse proxy écrit par les mêmes que ceux qui ont écrits memcached (lisez le Chapitre 13).

Avec les serveurs web à présent mis en grappe, notre architecture évolutive commence à appaître comme étant un peu plus complexe, comme le montre la Figure 20-4.

Figure 20-4: Une configuration serveurs redondants et à répartition de charge.

Notez que dans le diagramme les serveurs web sont considérés comme des «cluster» afin d’indiquer que le nombre de serveurs est variable. Une fois que vous avez un répartiteur de charge en frontal, vous pouvez facilement ajouter et retirer des serveurs web sans une seconde d’interruption de service.

Devenir gros

À ce stade, les prochaines étapes sont des dérivées de la précédente:

• lorsque vous aurez besoin de plus de performances en matière de base de données, vous devrez ajouter des serveurs de base de données répliqués. MySQL inclut des primites de réplications; les utilisateurs de PostgreSQL doivent regarder vers Slony (http://www.djangoproject.com/r/slony/) et pgpool (http://www.djangoproject.com/r/pgpool/) pour la réplication et les files de connection, respectivement.
• Si un seul répartiteur de charge n’est pas suffisant, vous pouvez ajouter d’autres machines frontales et répartir entre elles en utilisant l’allocation circulaire DNS.
• Si un seul serveur de médias ne suffit pas, vous pouvez ajouter plus de serveurs de médias et répartir la charge avec votre grappe de répartition de charge.
• Si vous avez besoin de plus de stockage du cache, vous pouvez ajouter des serveurs de cache dédiés.
• à toutes ces étapes, si un cluster n’est pas performant, vous pouvez ajouter plus de serveur à la grappe.

Après quelques unes de ces itérations, une architecture de grande envergure peut ressembler à la Figure 20-5.

Figure 20-5. Un exemple de configuration de Django à grande échelle.

Bien que nous n’ayons montrer que deux ou trois serveurs à chaque niveau, il n’y a pas de limitations fondamentale au nombre de serveur que vous pouvez ajouter.

Une fois que vous êtes arrivé à ce niveau, vous avez peu d’options. L’annexe A propose quelques informations de quelques développeurs responsable d’installations Django de grande envergure. Si vous prévoyez un site Django à fort trafic, cela vaut le coup de le lire.

Rien ne vaut trop de RAM

Au moment de l’écriture de ce livre, la RAM vraiment chère coûte environ 200$ le giga - des cacahuètes comparé au temps passé à optimiser les choses par ailleurs. Achetez autant de RAM que vos moyens le permettent, puis achetez en un peu plus.

Des processeurs plus rapides n’améliorerons pas tellement plus les performances; la plupart des serveurs web passent 90% de leur temps à attendre des E/S disque. Dès que vous commencez à swaper, les performances vont se dégrader. Des disques plus rapides peuvent améliorer un peu la chose, mais ils sont plus honéreux que la RAM, ainsi donc cela ne compte pas vraiment.

Si vous avez de multiples serveurs, le premier endroit où ajouter votre RAM est dans les serveurs de base de données. Si vous le pouvez, achetez assez de RAM pour placer l’intégralité de votre base en mémoire. Ceci ne devrait pas être difficile. La base de données de LJWorld.com, constituée de près d’un demi millions d’articles depuis 1989, fait moins de 2GB.

Ensuite, ajoutez de la RAM à votre serveur web. La situation idéale est celle où aucun serveur de swap - jamais. Si vous atteignez ce point, vous devriez être en mesure de resister à un trafic normal.

Désactivez le Keep-Alive

Keep-Alive est une fonctionnalité de HTTP qui autorise les requêtes HTTP multiples à être servies sur une connection TCP unique, évitant ainsi la surcharge du TCP setup/teardown.

Ceci semble bon au premier abord, mais peut tuer les performances d’un site Django? Si vous servez correctement les médias depuis un serveur dissocié, chaque utilisateur naviguant sur votre site ne demandera qu’une page à votre serveur Django toutes les 10 secondes environ. Ceci laisse les serveurs HTTP attendre la prochaine requête keep-alive, alors qu’un serveur HTTP paresseux consomme la RAM qu’un serveur actif pourrait utiliser.

Utiliser memcached

Bien que Django supporte de nombreux moteur de cache différents, aucun d’entre eux n’est aussi proche de la rapidité de memcached. Si vous avez un site à fort trafic, ne perdez pas votre temps avec les autre moteurs - utilisez directement memcached.

Utiliser memcached souvent

Bien sûr, sélectionner memcached ne vous sert à rien si vous ne l’utilisez pas. Le Chapitre 13 est ici votre meilleur ami: apprenez comment utiliser le framework de cache de Django, et utiliser partout où c’est possible. Le cache agressif, préemptif, est habituellement la seule chose qui gardera un site disponible sous fort trafic.

Rejoindre la conversation

Chaque pièce de la pile Django - depuis Linux à Apache en passant pas PostgreSQL ou MySQL - possèdent de grandes communautés derrière elles. Si vous voulez vraiment gagner ce dernier 1% des capacités des serveurs, rejoignez la communauté open-source derrière votre logiciel et demandez de l’aide. La plupart des membres de la communauté des logiciels Libres seront heureux de vous aider.

N’hésitez pas à rejoindre la communauté Django. Vos humble auteurs (et traducteurs :)) sont simplement deux membres d’un groupe grandissant de développeurs Django incroyablement actifs. Notre communauté à une grande quantité d’expérience collective à offrir.