Comment servir Django avec Bjoern

Bonjour le monde!

Si vous avez déjà eu envie de servir un nombre plus élévé de requetes alors le server wsgi Bjoern est fait pour vous.

Introduction

On caractérise l'efficacité d'un serveur web par certains critères à savoir:

• le nombre de requetes qu'il peut traiter par secondes
• la latence, le temps d'attente pour recevoir le resultat d'une requete
• la quantité d'erreurs, qui est juste le nombre de fois qu'il annule une requête

Le WSGI est le protocole utilisé par les applications et serveurs web Python. C'est un standard. Après des recherches je suis tombé sur cette comparaison des serveurs WSGI https://www.appdynamics.com/blog/engineering/a-performance-analysis-of-python-wsgi-servers-part-2/ il en ressort que les 2 meilleurs servers sont Bjoern et CherryPy. Nous allons donc voir comment configurer Bjoern pour servir une application Django parce que comparé à Gunicorn qui figure dans beaucoup de tutoriel il est largement meilleur.

Installation

On va proceder à l'installation de Bjorn sur un système Ubuntu. Les instructions devraient fonctionner pour n'importe quel autre système Linux moyennant quelques modifications. Installons les fichiers de developpement de la librairie libev sudo apt install libev-dev Maintenant installons bjoern, de préférence dans un environnement virtuel pip install bjoern

Utilisation

Un server a besoin d'un objet de type application WSGI. 🤔 Vous allez me demander sûrement où se trouve cet objet quand vous faites python manage.py runserver alors il se trouve dans le fichier wsgi.py qui se trouve dans le dossier de votre projet à coté de settings.py application = get_wsgi_application() cette ligne ci dessous correspond à l'instanciation de l'application wsgi.

Donc créer un fichier fast.py à coté de votre fichier manage.py et mettez le contenu ci-après

import bjoern

import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'votreproject.settings')

application = get_wsgi_application()

bjoern.run(application, '127.0.0.1', 8000)

print("Server started")

Enregistrer et pour lancer, faites juste python fast.py

Ouvrez ensuite votre navigateur à l'adresse localhost:8000 Votre site va s'ouvrir mais sans fichier css et js. En effet Bjoern est adapté pour utilisation en prodution, en developpement utilisé plutot la bonne vielle commande python manage.py runserver

Maintenant il n'est pas adapté de servir directement l'application. Il est préferable et recommandé d'utiliser un autre serveur http mais en reverse proxy. Apache et Nginx conviennent pour cette tache. Voyons voir la configuration pour Nginx.

Créer un fichier test.conf dans le dossier de config de Nginx sur Ubuntu il s'agit de /etc/nginx/conf.d/ Donc faites nano /etc/nginx/conf.d/test.conf Et mettez dedans

server {
    server_name server.domain;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /chemin/absolu/vers/votre/project;
    }

    location /media/ {  
        root /chemin/absolu/vers/votre/project;
    }

    location / {
        include proxy_params;
        proxy_pass http://127.0.0.1:8000;
    }

    listen 80;
}

Sauvegardez et redemarrez nginx service nginx restart ou systemctl restart nginx

Voilà! Votre application est fin prete pour servir des centaines de milliers de requetes par seconde sans crasher 👌🏽

NB: Cette configuration est celle qui est utilisé pour servir le site web de la communauté PyCM https://github.com/py-cm/website/blob/master/src/pycm/fast.py

Conclusion

Cet article vous a montré comment obtenir un meilleur rendement pour votre application django. C'est la 1ere étape ci vous rencontrer des soucis de lenteur et de crash. Si cette solution ne marche pas considerer qu'il faut deja augementer les caracteristiques de votre serveur (RAM et CPU). Le protocole WSGI est dit synchrone, il faut donc lancer un nouveau thread ou un processus enfant pour chaque requete. L'une des particularités de Bjoern c'est qu'il utilise un seul thread. Pour des vitesses plus élévées, proches de celle de nodeJS, il faut se tourner vers le protocole ASGI. Qui est juste l'analogue de WSGI mais qui fonctionne en asynchrone et donc est adapté pour le HTTP/2 et les Websockets. Notons que Django 3.0, est ASGI compatible contrairement aux précedentes versions. La version 3.1 en cours de developpement a integré les Views asynchrones. N'est elle pas belle la vie ? Je vous remercie d'avoir lu cet article, si vous l'avez aimé, laisser un Like et partager.