30 août 2019

htaccess sur NGINX, un problème de performances sur les sites à fort trafic. Pourquoi devriez-vous utiliser NGINX.

L'alternative à Apache pour les sites performants.

Il existe des situations comme celles des sites à fort trafic (sites avec des millions de visiteurs par jour pour être clair) dans lesquelles la recette idéale est recherchée au niveau technologique et systémique pour pouvoir offrir des performances maximales au coût de calcul le plus bas possible. Si nous regardons tous les projets de sites à fort trafic basés sur des technologies open source (et donc pas le .net de Microsoft par exemple) nous constaterons que nous aurons comme seule constante et dénominateur un serveur web dont nous avons parlé dans cet article : Nginx.

Parmi les innombrables PRO NGINX a aussi un apparent "contre", à savoir celui de ne pas avoir de support htaccess comme le plus connu Apache Web Server.

Qu'est-ce que htaccess ?

Le fichier .htaccess (Hypertext Access) est un fichier de configuration grâce auquel vous pouvez modifier les paramètres d'un répertoire spécifique (c'est-à-dire d'un dossier spécifique). Par répertoire spécifique, dans ce contexte, nous entendons que tous les paramètres choisis pour ce répertoire spécifique s'appliquent également à tous les sous-répertoires (ou sous-dossiers). Un fichier .htaccess ne peut être utilisé qu'avec des serveurs NCSA compatibles, tels que des serveurs Apache prenant en charge des modules tels que mod_rewrite. Ce type de fichier fait partie intégrante des configurations du serveur et toute modification de celui-ci est automatiquement répercutée sur le site.

NGINX ne prend pas en charge htaccess

 

Quelqu'un croit à tort que la raison en est une position prise par le développeur liée à la "paresse" de l'implémentation d'une fonctionnalité qui est certainement pratique sur Apache.

Mais comme nous l'avons appris du monde de la Formule 1 et de la vitesse en général, si nous voulons courir vite et être compétitifs, nous devons faire quelques sacrifices afin d'alléger le poids du véhicule ou du serveur Web.

Dans ce cas précisément le manque de support de htaccess n'est pas un défaut, mais plutôt une fonctionnalité. Ou plus précisément un de ces rares cas où ne pas avoir quelque chose n'est pas un défaut mais une vertu.

Si vous voulez utiliser .htaccess à tout prix, vous vous trompez probablement et vous ne devriez pas.

Pourquoi ?

C'est une très bonne question. Pour commencer, pour que .htaccess fonctionne Apache doit vérifier CHAQUE répertoire dans le chemin requis pour qu'un fichier .htaccess existe et, s'il existe, il lit TOUT et l'analyse. Cela se produit pour CHAQUE demande. En fait, n'oubliez pas que lorsque vous modifiez ce fichier unique, le changement passe immédiatement dans le port sans avoir à redémarrer le serveur Web, précisément parce qu'Apache le lit à chaque fois.

Nombres

http://example.com/site/files/images/layout/header.png

Disons que nous ne créons aucun alias et que le système de fichiers est le chemin. Ce cas est un scénario courant avec la plupart des sites.

Il y a le répertoire /, donc site/, fichiers/, images/ et layout/. Cela équivaut à 5 répertoires pouvant contenir un fichier .htaccess. Disons que vous avez ajouté un .htaccess dans /, des fichiers / et des images /. Il existe trois fichiers .htaccess. C'est assez typique.

Maintenant, les nombres, qui sont 6 statistiques du système de fichiers et 4 lectures du système de fichiers. Dont un pour le fichier demandé. Cela se produit à chaque lecture. On ignorera le temps d'analyse pour qu'il soit NGINX qu'Apache doit faire cela et nous considérerons que le décalage horaire pour cela est négligeable.

Demandes / Heure Statistiques NGINX Lectures NGINX FS Statistiques Apache Lectures Apache FS Commentaire
1 1 1 6 4 Demande unique [pratiquement pas de charge]
10 10 10 60 40 Dix requêtes [pratiquement pas de charge]
3.600 3.600 3.600 21.600 14.400 1 req/sec [très faible charge]
144.000 144.000 144.000 864.000 576.000 40 req/sec [Trafic modéré - rien de très gros]
324.000 324.000 324.000 1,944,00 1.296.000 90 req / sec [Site à trafic plus élevé - pas massif]
576.000 576.000 576.000 3.456.000 2.304.000 160 req/sec [Trafic assez élevé, bien que pas encore massif]

 

Encore plus de chiffres et de lenteur

La valeur par défaut pour Apache est d'utiliser AllowOverride All. Jetons un coup d'œil à cela pour un site Web Drupal. Une image pour le thème. Si votre site Web DocRoot est activé, /var/www/drupal6/nous venons d'ajouter plus de statistiques sur le système de fichiers. Cela ajoute 3 statistiques par demande. Il s'agit d'une installation Apache / Drupal incroyablement courante. C'est le résultat final d'innombrables guides là-bas.

/var/www/drupal6/sites/example.com/themes/yourtheme/images/layout/header.png

Deux fichiers .htaccess seront dans ce chemin à moins que vous ne les créiez. Je suppose que vous en avez ajouté un dans /var/www/ car c'est courant.

Demandes / Heure Statistiques NGINX Lectures NGINX FS Statistiques Apache FD Lectures Apache FS Commentaire
144.000 144.000 144.000 1.296.000 576.000 40 req/sec
324.000 324.000 324.000 2.916.000 1.296.000 90 req/sec
576.000 576.000 576.000 51.840.000 2.304.000 160 req/sec

Interprétation des données

Pour être très simple sans trop de mots et de diplomatie, Apache fait au pire 100 fois les accès I/O par rapport à NGINX, au mieux l'exemple ci-dessus en fait 10 fois plus.

Et nous voulions proposer un cas courant qui ne soit ni trop optimal ni trop mauvais, mais pensons à ces répertoires imbriqués qui vont en profondeur pour 20 ou 30 nœuds. Avez-vous une idée de ce que cela devient? Apache effectue 1000 opérations de plus qu'une seule NGINX. Beaucoup trop pour même le fanboy le plus inconditionnel d'Apache et de htaccess.

Retour sur les performances pratiques

Un vrai retour de performance implique qu'il y aura des E/S disque vraiment importantes quand on a un site très chargé et beaucoup de requêtes par seconde. Imaginez que vous ayez acheté le dernier disque SSD 1Gbit/s nVME SSD pour garantir les performances et le débit d'E/S sur votre serveur WordPress hautes performances, puis allez y mettre Apache. Dans certains cas, vous dégraderez tellement les performances et les E/S, même au niveau du noyau, que vous obtiendrez les mêmes performances qu'un disque dur SATA mécanique.

Apache est donc bon pour les sites classiques mais pas pour les sites performants.

Vous êtes Apache, vous souhaitez migrer vers NGINX mais avez-vous forcément besoin de htaccess ?

L'une des raisons pour lesquelles vous n'êtes pas réticent à passer à NGINX est l'habitude avec laquelle vous avez grandi professionnellement pour utiliser Apache fourni par défaut sur des panneaux comme cPAnel ou Plesk. Si vous êtes né, grandissez avec une technologie, il est normal et paisible de mourir même avec exactement la même technologie. Il faut un peu de curiosité et d'autocritique pour remettre en question certaines fausses croyances et essayer de faire mieux en utilisant une solution technologique qui est encore montée sur la plupart des sites à fort trafic.

Le principal problème est de continuer à utiliser .htaccess sur un système qui ne prend pas réellement en charge .htaccess. Concept qui si lu rapidement vous donne envie de fermer la page et de continuer avec le bon vieux Apache, mais attendez peut-être que nous n'avons pas compris qu'il y a plus que vous devriez savoir et que vous aimerez sûrement.

Ne pas lire htaccess ne signifie pas que vous ne pouvez pas utiliser les règles de réécriture

Nous avons écrit jusqu'à présent que NGINX ne lit pas les fichiers htaccess mais non pas qu'il ne peut pas profiter des fonctionnalités de réécriture. htaccess est un format propriétaire utilisé essentiellement uniquement par Apache et donc dire que NGINX ne lit pas htaccess c'est un peu comme dire que NGINX ne lit pas un format propriétaire d'Apache mais pas qu'il peut avoir la même fonctionnalité à sa manière, selon à ses propres règles, mieux que htaccess.

Le seul problème est d'essayer de comprendre comment vous pouvez convertir un projet d'APACHE htaccess en réécriture NGINX.

Réécrire les règles sur NGINX

NGINX, comme nous l'avons dit, prend en charge les règles de réécriture à sa manière. Il le fait selon sa propre syntaxe complètement différente de celle de htaccess, il le fait selon sa philosophie qui est de respecter les règles au démarrage du serveur web et uniquement à ce moment-là. Par conséquent, les règles de réécriture contrairement à Apache seront écrites dans la configuration de l'hôte virtuel et seront valables pour toute la durée du serveur Web. Il n'y a aucune possibilité de créer un fichier .htaccess (ou tout équivalent NGINX) et de le faire digérer par le serveur Web sans redémarrer le service.

Sur NGINX si vous souhaitez insérer une nouvelle règle de réécriture comme une redirection 301 triviale d'une ancienne page supprimée vers une nouvelle, vous devez éditer le fichier de configuration du vhost en question tel que sitename.conf ajouter la règle de réécriture puis recharger et redémarrer le serveur web selon la syntaxe du service nginx reload ou service nginx restart pour recharger la nouvelle règle insérée et la faire fonctionner correctement.

Problèmes commerciaux et organisationnels

L'un des problèmes importants du manque de diffusion de NGINX ainsi que du manque de support .htaccess est le fait que pour écrire de nouvelles règles de réécriture dans le vhost vous devez obligatoirement aller sur le vhost et redémarrer le serveur web. Les deux opérations nécessitent des privilèges de superutilisateur ou root. Dans un environnement d'hébergement mutualisé où l'utilisateur moyen n'est pas un ingénieur système, mettre la main à ces tâches aurait été totalement impossible, compromettant ainsi la vente de services d'hébergement à bas prix ou pour l'utilisateur moyen.

Ce n'est que récemment que certains panneaux de contrôle comme Plesk et cPanel ont implémenté via l'interface pointer-cliquer habituelle la possibilité de choisir le serveur Web à utiliser entre NGINX et Apache (et aussi un mix des deux solutions via reverse proxy) mais malgré cela de nombreux webmasters, développeurs et référenceurs continuent d'avoir du mal à utiliser le même vieil Apache.

 

Convertir htaccess en NGINX

Nous pourrions faire le phénomène et dire qu'à la base convertir un .htaccess en NGINX n'est pas très complexe car la syntaxe elle-même est assez simple (à notre avis encore plus facile que celle de htaccess natif), mais alors ce que nous vous dirons quand vous en aurez besoin convertir ces 500 lignes de réécriture de htaccess en NGINX ? 3 ou 4 jours pour convertir toutes les règles ? Non merci.

Il existe des solutions plus rapides et plus immédiates mises à disposition par les entreprises qui ont décidé de rendre accessibles au public des convertisseurs en ligne qui vous permettent de convertir les règles de réécriture de htaccess vers NGINX.

Malheureusement, puisqu'il n'y a rien d'officiel et d'efficace, la plupart ont tendance à produire des règles qui ne fonctionnent pas ou qui fonctionnent mais s'approchent avec une mauvaise syntaxe.

Cependant, le meilleur en circulation qui permet dans 99% des cas de convertir des règles moyennement complexes (comme la réécriture 301 et autres) est celui que vous trouverez sur ce lien

C'est en fait comme son nom l'indique un convertisseur htaccess qui vous permet de convertir htaccess en règles NGINX. Voici par exemple une vraie utilisation de ce soir dont nous avions besoin pour faire venir un nouveau site client d'Apache vers NGINX pour des raisons de performances.

htaccess convertir nginx

En collant les règles .htaccess dans la section htaccess et en appuyant sur le bouton "convertir", nous renverrons la syntaxe NGINX respective que nous copierons et collerons dans la configuration de l'hôte virtuel NGINX, puis redémarrerons le serveur Web pour tester l'exactitude.

Conclusions

Si vous avez des sites de boucherie ou de pizzeria sous votre maison avec quelques visites par mois allez bien avec Apache et .htaccess, si vous gérez des sites à fort trafic et très performant utilisez NGINX comme le font tous les sites à très fort trafic.

Nous utilisons NGINX et laissons Apache aux amateurs.

 

 

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page