Optimiser les performances de Python avec NGINX, partie 1 : service web et mise en cache

Floyd SmithDirecteur du marketing de contenu

Introduction – Comment NGINX est utilisé avec Python

Python est réputé pour être facile et agréable à utiliser, pour simplifier le développement logiciel et pour offrir des performances d’exécution réputées supérieures à celles des autres langages de script. (Même si la dernière version de PHP, PHP 7, pourrait bien lui donner du fil à retordre.)

Tout le monde souhaite que son site web et son application fonctionnent plus rapidement. Par ailleurs, tout site web dont le trafic augmente ou connaît des pics soudains est exposé à des problèmes de performances et à des interruptions de service, qui surviennent souvent au pire moment, c’est-à-dire pendant les périodes de plus forte affluence. En outre, presque tous les sites web rencontrent des problèmes de performances et des interruptions de service, que leur trafic augmente régulièrement ou qu’ils connaissent de brusques pics d’utilisation.

C’est là qu’interviennent NGINX et NGINX Plus. Ils améliorent les performances des sites Web de trois manières différentes :

1. En tant que serveur web – NGINX a été initialement développé pour résoudre le problème des 10 000 connexions simultanées (C10K) – c’est-à-dire pour prendre facilement en charge 10 000 connexions simultanées ou plus. Utiliser NGINX comme serveur web pour votre application Python accélère votre site, même lorsque le trafic est faible. Lorsque vous comptez plusieurs milliers d’utilisateurs, il est pratiquement certain que vous bénéficierez de performances nettement supérieures, de moins de plantages et de moins d’indisponibilités. Vous pouvez également mettre en cache des fichiers statiques ou utiliser la mise en cache de courte durée sur votre serveur web NGINX, même si ces deux solutions fonctionnent mieux sur un serveur proxy inverse NGINX distinct (voir le paragraphe suivant).
2. En tant que serveur proxy inverse – Vous pouvez « insérer NGINX » comme serveur proxy inverse devant votre infrastructure de serveurs d’applications actuelle. NGINX fait face au Web et transmet les requêtes à votre serveur d’applications. Cette « astuce insolite » accélère votre site Web, réduit les temps d’arrêt et la consommation de ressources serveur, et améliore la sécurité. Vous pouvez également mettre en cache les fichiers statiques sur le serveur proxy inverse (ce qui est très efficace), ajouter la mise en cache de courte durée du contenu dynamique afin de réduire la charge sur l’application elle-même, et bien plus encore.
3. En tant qu’équilibreur de charge pour plusieurs serveurs d’applications – Commencez par déployer un serveur proxy inverse. Faites ensuite évoluer horizontalement votre infrastructure en exécutant plusieurs serveurs d’applications en parallèle et en utilisant NGINX ou NGINX Plus pour répartir la charge du trafic entre eux. Avec ce type de déploiement, vous pouvez facilement adapter les performances de votre site web aux besoins en trafic, tout en améliorant sa fiabilité et sa disponibilité. Si vous souhaitez qu’une session utilisateur donnée reste sur le même serveur, configurez l’équilibreur de charge pour prendre en charge la persistance de session.

NGINX et NGINX Plus offrent des avantages, que vous les utilisiez comme serveur web pour votre application Python, comme serveur proxy inverse, comme équilibreur de charge ou à ces trois fins.

Dans ce premier article d’une série en deux parties, nous présentons cinq conseils pour améliorer les performances de vos applications Python, notamment l’utilisation de NGINX et NGINX Plus comme serveur Web, la mise en cache des fichiers statiques et la mise en microcache des fichiers générés par les applications. Dans la deuxième partie, nous expliquerons comment utiliser NGINX et NGINX Plus comme serveur proxy inverse et comme répartiteur de charge pour plusieurs serveurs d’applications.

Conseil n° 1 – Identifiez les goulots d’étranglement des performances de Python

Les performances de votre application Python sont importantes dans deux situations très différentes : d’une part, avec un nombre d’utilisateurs habituel et « raisonnable » ; d’autre part, en cas de forte charge. De nombreux propriétaires de sites ne se préoccupent pas assez des performances lorsque la charge est faible, alors que, selon nous, chaque dixième de seconde du temps de réponse devrait être une préoccupation majeure. Gagner quelques millisecondes sur les temps de réponse est une tâche difficile et ingrate, mais cela améliore la satisfaction des utilisateurs et les résultats de l’entreprise.

Cependant, cet article de blog, ainsi que la deuxième partie qui l’accompagne, portent plutôt sur le scénario qui inquiète tout le monde : les problèmes de performances qui surviennent lorsqu’un site connaît un fort trafic, comme d’importants ralentissements et des plantages. En outre, de nombreuses attaques informatiques reproduisent les effets d’une hausse soudaine du nombre d’utilisateurs, et l’amélioration des performances du site constitue souvent une étape importante pour faire face aux attaques également.

Avec un système qui alloue une certaine quantité de mémoire à chaque utilisateur, comme Apache HTTP Server, l’arrivée de nouveaux utilisateurs finit par saturer la mémoire physique à mesure qu’ils se multiplient. Le serveur commence alors à utiliser l’espace d’échange sur le disque, les performances chutent brutalement, entraînant ralentissements et plantages. La migration vers NGINX, telle qu’elle est décrite dans cet article de blog, contribue à résoudre ce problème.

Python est particulièrement sujet aux problèmes de performances liés à la mémoire, car il utilise généralement davantage de mémoire que les autres langages de script pour accomplir ses tâches (ce qui lui permet en contrepartie de les exécuter plus rapidement). Ainsi, toutes choses égales par ailleurs, votre application basée sur Python risque de « s’effondrer » avec un nombre d’utilisateurs inférieur à celui que pourrait supporter une application écrite dans un autre langage.

L’optimisation de votre application peut être utile dans une certaine mesure, mais ce n’est généralement ni la meilleure ni la plus rapide des solutions aux problèmes de performances d’un site liés au trafic. Les étapes présentées dans cet article de blog, ainsi que dans la deuxième partie qui l’accompagne, constituent les moyens les plus efficaces et les plus rapides de résoudre ces problèmes. Une fois ces étapes suivies, vous pourrez bien entendu revenir à votre application pour l’améliorer ou la réécrire afin d’utiliser une architecture de microservices.

Conseil n° 2 – Choisissez un déploiement sur un seul serveur ou sur plusieurs serveurs

Les petits sites web fonctionnent très bien lorsqu’ils sont déployés sur un seul serveur. Les grands sites web nécessitent plusieurs serveurs. Mais si vous vous situez dans la zone grise entre les deux — ou si votre site est en train de passer d’un petit à un grand site — vous devrez faire des choix intéressants.

Si votre déploiement repose sur un seul serveur, vous vous exposez à des risques importants en cas de pics de trafic ou d’augmentation rapide du trafic global. Votre capacité de montée en charge est limitée. Parmi les solutions possibles figurent l’optimisation de votre application, le passage de votre serveur web à NGINX, l’acquisition d’un serveur plus puissant et plus rapide, ou encore l’externalisation du stockage vers un réseau de diffusion de contenu (CDN). Chacune de ces options demande du temps à mettre en œuvre, entraîne des coûts et risque d’introduire des bogues ou des problèmes lors de son déploiement.

De plus, avec un déploiement sur un serveur unique, votre site présente par définition un point de défaillance unique – et bon nombre des problèmes susceptibles de rendre votre site indisponible n’ont pas de solution simple ou rapide.

Si vous remplacez votre serveur par NGINX dans un déploiement à serveur unique, vous pouvez choisir librement entre NGINX Open Source et NGINX Plus. NGINX Plus inclut une assistance de niveau entreprise et des fonctionnalités supplémentaires. Certaines de ces fonctionnalités, telles que la surveillance de l’activité en temps réel, sont pertinentes pour un déploiement à serveur unique, tandis que d’autres, telles que la répartition de charge et la persistance des sessions, entrent en jeu si vous utilisez NGINX Plus comme serveur proxy inverse dans un déploiement multiserveur.

Tout bien considéré, à moins que vous ne soyez certain que votre site restera de petite taille pendant encore longtemps et que les interruptions de service ne constituent pas une préoccupation majeure, un déploiement sur un serveur unique présente certains risques. Un déploiement multiserveur offre une évolutivité pratiquement illimitée : il est possible d’éliminer les points de défaillance uniques et d’atteindre le niveau de performances souhaité, tout en pouvant augmenter rapidement la capacité.

Conseil n° 3 – Passez votre serveur web à NGINX

Aux débuts du Web, le nom « Apache » était synonyme de « serveur Web ». Mais NGINX a été développé au début des années 2000 et gagne régulièrement en popularité ; il est déjà le serveur Web nº 1 parmi les 1 000, 10 000, 100 000 et [ngx_snippet name=’proportion-top-sites’] sites les plus populaires au monde.

NGINX a été développé pour résoudre le problème C10K – c’est-à-dire pour gérer plus de 10 000 connexions simultanées avec une quantité de mémoire donnée. Les autres serveurs web ont besoin d’un bloc de mémoire pour chaque connexion. Ils finissent donc par manquer de mémoire physique, ralentissent ou tombent en panne lorsque des milliers d’utilisateurs veulent accéder simultanément à un site. NGINX traite chaque requête séparément et s’adapte sans difficulté à un nombre bien plus élevé d’utilisateurs. (Il est également parfaitement adapté à d’autres usages, comme nous le verrons ci-dessous.)

Vous trouverez ci-dessous une vue d’ensemble de l’architecture de NGINX.

Dans le schéma, un serveur d’applications Python correspond au bloc Serveur d’applications du backend, auquel l’accès s’effectue via FastCGI. NGINX ne « sait » pas exécuter Python ; il lui faut donc une passerelle vers un environnement qui le permet. FastCGI est une interface largement utilisée pour PHP, Python et d’autres langages.

Cependant, l’interface Web Server Gateway Interface (WSGI) est une solution plus couramment utilisée pour assurer la communication entre Python et NGINX. WSGI fonctionne dans des environnements multithreads et multiprocessus, ce qui lui permet de s’adapter efficacement à toutes les options de déploiement mentionnées dans cet article de blog.

Si vous adoptez NGINX comme serveur web, vous trouverez de nombreuses ressources pour vous accompagner dans les différentes étapes :

• Configuration de gunicorn – « Green Unicorn », un serveur WSGI populaire, pour une utilisation avec NGINX.
• Configuration d’uWSGI – Un autre serveur WSGI populaire à utiliser avec NGINX. uWSGI prend directement en charge NGINX.
• Utilisation de uWSGI, NGINX et Django – Un framework web Python populaire.

Cet extrait montre comment vous pourriez configurer NGINX pour l’utiliser avec uWSGI – dans le cas présent, pour un projet utilisant le framework Python Django :

http {    # ...
    upstream django {
       server 127.0.0.1:29000;
    }

    server {
        listen 80;
        server_name myapp.example.com;

        root /var/www/myapp/html;

        location / {
            index index.html;
        }

        location /static/  {
            alias /var/django/projects/myapp/static/;
        }

        location /main {
            include /etc/nginx/uwsgi_params;
            uwsgi_pass django;

            uwsgi_param Host $host;
            uwsgi_param X-Real-IP $remote_addr;
            uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
            uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
        }
    }
}

Conseil 4 – Mettez en cache les fichiers statiques

La mise en cache du contenu statique consiste à conserver une copie des fichiers qui ne changent pas très souvent – parfois seulement toutes les quelques heures, voire jamais – à un emplacement autre que le serveur d’applications. Une image JPEG affichée sur une page web est un exemple typique de contenu statique.

La mise en cache des fichiers statiques est un moyen courant d’améliorer les performances des applications. Elle s’effectue en réalité à plusieurs niveaux :

• Dans le navigateur de l’utilisateur
• Chez les fournisseurs d’accès à Internet, à plusieurs niveaux – du réseau interne d’une entreprise à un fournisseur d’accès à Internet (FAI)
• Sur un serveur web, comme nous allons le décrire ici

La mise en cache des fichiers statiques sur le serveur web présente deux avantages :

• Diffusion plus rapide auprès de l’utilisateur – NGINX est optimisé pour la mise en cache des fichiers statiques et traite les requêtes de contenu statique beaucoup plus rapidement qu’un serveur d’applications.
• Réduction de la charge sur le serveur d’applications – Le serveur d’applications ne reçoit même pas les requêtes concernant les fichiers statiques mis en cache, car le serveur web y répond.

La mise en cache des fichiers statiques fonctionne bien dans une configuration à serveur unique, mais les ressources matérielles sous-jacentes restent partagées entre le serveur web et le serveur d’applications. Si le serveur web mobilise ces ressources pour récupérer un fichier mis en cache – même de manière très efficace – elles ne sont pas disponibles pour l’application, ce qui peut la ralentir dans une certaine mesure.

Pour permettre la mise en cache par le navigateur, configurez correctement les en-têtes HTTP pour les fichiers statiques. Prenez en compte l’en-tête HTTP « Cache-Control » (et en particulier son paramètre « max-age »), l’en-tête « Expires » et les balises « Entity ». Pour une bonne introduction à ce sujet, consultez « Utilisation de NGINX et NGINX Plus comme passerelle d’application avec uWSGI et Django » dans le Guide d’administration de NGINX Plus.

Le code suivant configure NGINX pour mettre en cache les fichiers statiques, notamment les fichiers JPEG, GIF, PNG, les vidéos MP4, les fichiers PowerPoint et bien d’autres. Remplacez www.example.com par l’URL de votre serveur web.

server {    # substitute your web server's URL for "www.example.com"
    server_name www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

   location / {
        try_files $uri $uri/ /index.php?$args;
    }

   location ~ .php$ {
        try_files $uri =404;
        include fastcgi_params;
        # substitute the socket, or address and port, of your Python server
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        #fastcgi_pass 127.0.0.1:9000;
 	}  

   location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
                  |jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
                  |midi|wav|bmp|rtf)$ {
        expires max;
        log_not_found off;
        access_log off;
    }
}

Conseil 5 – Mettez en œuvre la mise en cache de courte durée

La mise en cache de très courte durée offre un potentiel considérable d’amélioration des performances des serveurs d’applications exécutant Python, PHP et d’autres langages. Du point de vue de la mise en cache, il existe trois types de pages web :

• Fichiers statiques – Ils peuvent être mis en cache, comme décrit dans le conseil 4.
• Pages non personnalisées générées par l’application – Il n’est généralement pas judicieux de les mettre en cache, car elles doivent être à jour. Prenons l’exemple d’une page présentée à un utilisateur non connecté sur un site d’e-commerce (voir le point suivant) : les produits disponibles, les recommandations de produits similaires, etc. peuvent changer constamment. Il est donc important de lui fournir une page à jour. Toutefois, si un autre utilisateur arrive, par exemple un dixième de seconde plus tard, il peut être tout à fait acceptable de lui présenter la même page qu’à l’utilisateur précédent.
• Pages personnalisées générées par l’application – Il n’est pas utile de les mettre en cache, car elles sont propres à chaque utilisateur et il est peu probable qu’un même utilisateur consulte deux fois la même page personnalisée. Par exemple, une page de site e-commerce destinée à un utilisateur connecté ne peut pas être affichée à d’autres utilisateurs.

Les fichiers statiques et les fichiers non personnalisés générés par l’application peuvent être mis en cache

La mise en cache de très courte durée est utile pour le deuxième type de page décrit ci-dessus : les pages générées par l’application et non personnalisées. Le terme « micro » fait référence à une durée très brève. Lorsque votre site génère la même page plusieurs fois par seconde, sa fraîcheur ne sera guère affectée si vous la mettez en cache pendant une seconde. Pourtant, cette brève période de mise en cache peut considérablement alléger la charge du serveur d’applications, en particulier lors des pics de trafic. Au lieu de générer 10, 20 ou 100 pages (avec le même contenu) pendant la durée de validité du cache, il ne génère une page donnée qu’une seule fois ; celle-ci est ensuite mise en cache et distribuée à de nombreux utilisateurs depuis le cache.

L’effet tient presque du miracle. Un serveur lent lorsqu’il traite des dizaines de requêtes par seconde devient très rapide lorsqu’il n’en traite qu’une seule. (Sans compter, bien sûr, les éventuelles pages personnalisées.) Notre collègue Owen Garrett a publié un billet de blog qui présente en détail les avantages de la mise en cache de très courte durée, avec le code de configuration correspondant. La principale modification, qui consiste à configurer un cache proxy avec un délai d’expiration d’une seconde, ne nécessite que quelques lignes de code de configuration.

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

Pour d’autres exemples de configuration, consultez l’article de blog de Tyler Hicks‑Wright consacré à Python et uWSGI avec NGINX.

Conclusion

Dans la première partie, nous avons passé en revue des solutions permettant d’améliorer les performances d’une implémentation Python sur un serveur unique, ainsi que la mise en cache, qui peut être déployée sur cette même implémentation ou exécutée sur un serveur proxy inverse ou un serveur de cache distinct. (La mise en cache est plus efficace sur un serveur distinct.) La partie suivante, Partie 2, décrit des solutions d’optimisation des performances qui nécessitent au moins deux serveurs.

Si vous souhaitez découvrir les fonctionnalités avancées de NGINX Plus pour votre application, telles que l’assistance, la surveillance de l’activité en temps réel et la reconfiguration à la volée, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Floyd SmithDirecteur du marketing de contenu

Autres articles de Floyd Smith