Quelle architecture logicielle pour un site Web fort trafic ?

On ne développe pas un site Web à fort trafic comme on développe un site institutionnel qui recevra quelques centaines de visites par jour. Quand les performances doivent être optimales, il est nécessaire d’adapter l’architecture logicielle du site Web. Quelles sont les technologies à mettre en oeuvre pour servir un maximum de visiteurs en un minimum de temps ?

Choisir le bon framework

symfony2Avant toute chose, il vous faudra opter pour un framework de développement supportant des techniques d’optimisations avancées :

  • précompilation,
  • gestion de caches,
  • Edge Side Include (ESI)

Ce dernier point est particulièrement important dès lors que vous souhaitez mettre en place une stratégie agressive de caching . En effet, la norme ESI éditée par Akamai permet de mettre en cache des morceaux de page tout en conservant certaines parties dynamiques : nom de l’utilisateur connecté, panier d’achats, news temps réel, etc.

Symfony 2 est particulièrement adapté puisqu’il gère nativement les ESI  et intègre un reverse proxy écrit en PHP pour les tester.

Mettre en place un front solide

varnishPour servir un grand nombre de visiteurs, il existe des technologies bien plus performantes que PHP. Vous devrez donc concevoir l’architecture du projet en limitant les appels vers PHP (ou en basculant vers d’autres technologies). Cela passe par la mise en place d’un front dédié aux services des pages et un back centré sur les aspects métiers.

L’objectif de cette séparation stricte est de réduire au maximum les appels vers les serveurs applicatifs en back tout en servant un maximum de pages en cache via le front.

Varnish et Squid sont des reverses proxies à placer en frontal des applications métiers. Ce sont eux qui répondent aux sollicitations :

  • soit en servant directement les pages en cache,
  • soit en appelant le serveur applicatif ;
  • soit un mix des deux lors de l’utilisation d’ESI.

Une bonne requête est une requête qui ne part pas

cache-httpLa mise en cache des ressources coté utilisateurs est la meilleure des techniques pour augmenter le nombre de visiteurs servis. En effet, la bonne requête est celle qui n’a pas besoin d’être lancée ! L’utilisation des entêtes suivants vous permettra d’éviter les appels inutiles :

  • Cache-Control
  • Expires
  • Last-Modified
  • ETag

Là encore, Symfony 2 est adapté puisqu’il gère nativement le cache au plus près de la norme HTTP : durée de vie, expiration, invalidation, etc. Un bundle tel que LiipCacheControl vous aidera également dans cette tâche sensible.

Du cache coté applicatif

redisDans un précédent article, je vous présentais succinctement les différents types de cache qu’il est possible d’utiliser pour optimiser une application Web. L’un des secrets pour accélérer drastiquement une application gérant de nombreuses données métier  est d’utiliser un cache applicatif. Dans le cadre d’application métier affichant des données dynamiques, plutôt que de calculer la réponse à chaque requête, il est possible de la précalculer régulièrement et de la placer dans des serveurs de cache. C’est cette représentation qui sera utilisée pour l’affichage et qui sera invalidée à intervalle plus ou moins régulier selon la fraîcheur souhaitée des données.

Issu de la mouvance NoSQL, Redis est un serveur clef/valeur évolutif gérant les accès concurrents, les données structurées et de nombreuses fonctionnalités puissantes. Il autorise la montée en charge ainsi que la sauvegarde asynchrone sur disque afin d’optimiser les performances.

Limiter les requêtes (en nombre et en poids)

compressÉvidement la mise en cache coté navigateur n’apporte un gain qu’à partir de la seconde requête effectuée par l’utilisateur. Celui-ci devra toujours récupérer les ressources lors de son premier appel. Il est donc nécessaire d’optimiser le nombre et le poids des requêtes en travaillant sur quatre chantiers :

  • la minification et l’assemblage des fichiers CSS et Javascript,
  • la réduction du nombre d’images via la construction de sprites (images concaténées),
  • la taille des fichiers : poids des CSS, Javascript, images, HTML,
  • l’utilisation de la compression GZIP pour l’envoi des données.

Des bundles tels que Assetic, Sprites et HTMLPurifierBundle pourront vous être utiles pour gérer ces problématiques.

Des technologies adaptées

website-scalabilityQuand on aborde les sites à fort trafic, on parle forcément d’architecture évolutive. Une architecture évolutive (scalable) permet avant tout de supporter des évolutions de charge en ajoutant ou retirant des serveurs (front, cache, applicatif, database) sans changer une ligne  de code hormis la configuration. La contrainte « site Web fort trafic » impose donc d’être prise en compte dès la phase de conception du projet afin d’éviter des coûts exorbitants de migration ultérieure voire de réécriture complète.

Ainsi, tout au long de la vie du projet, les technologies devront être minutieusement sélectionnées en ayant à l’esprit cette contrainte de scalabilité.

Conclusion

J’ai abordé quelques techniques et technologies telles que Symfony, Varnish, Squid, Redis permettant de gérer la montée en charge d’un site Web. L’écosystème Web évolue rapidement, n’hésitez donc pas à suggérer vos outils et technologies en commentaire.

  • Vincent DECAUX

    Les idées de base sont là ! Après, comme dit Jean-Marie, rien que le fait de choisir Nginx et PHP-FPM fait gagner de précieuses secondes. J’avais développé à l’époque un système de cache HTML pour Prestashop, qui permettait de ne servir que du HTML gzippé, et la différence sur serveur mutualisé était évidement impressionnante. Il était juste marrant de voir la réaction des clients ne comprenant pas pourquoi leurs informations ne se mettaient pas à jour à la seconde…

    Aussi, j’installe désormais le module Google Page Speed module, qui minifie et compresse et optimise les images et ressources automatiquement, comparé à Assetics ou autre, il est vraiment simple à utiliser, je vous conseille de jeter un oeil. Sans oublier l’aspect CDN qui soulage aussi énormément la plupart des infras.

    • François Roquefort

      Je viens de lire ta réponse : je vais jeter un œil. Merci beaucoup.

    • François Roquefort

      Après étude approfondie … comment dire …. c’est énorme et tellement puissant !!! Je sens que je vais me le tester celui-là. Cependant, dommage qu’il n’existe qu’en version Beta pour nginx.

  • Srinivasa Ramanujan

    On peux coder notre site en C, si la performance est plus importante que le coût de la maintenance.

  • LEROUX Jean-Marie

    Le côté serveur web est aussi un peu oublié : NGINX + PHP-FPM sera beaucoup plus performant qu’un APACHE + mod_php.
    Sans parler de node.js…

    Et en parlant de JS, mettre en place des traitements côté client avec les frameworks récents (Angular, Backbone, Ember, etc.) peut permettre de réduire la charge de traitement côté serveur.

    • François Roquefort

      Il ne manque plus à ton architecture qu’un petit service de cache (memcache par exemple). Au fait, à la base, je suis tombé ici car je cherche à voir si mon architecture est perfectible en terme de briques logicielles. Quelqu’un aurait-il une idée à ce propos ?

  • Stéphane

    Globalement d’accord excepté en ce qui concerne le choix de Symfony, qui est juste une bouse infâme en matière de performances… Mais bon, leurs commerciaux sont bon et du coup le marché de l’emploi survalorise ces profils. Il suffit de regarder un bench : http://www.techempower.com/benchmarks/

    Les vrais site web à fort trafic (en millions d’user/jour), n’utilisent pas symfony.

    • Nicolas Hachet

      Oui Symfony n’est pas ultra rapide (comparé à Phalcon ou à d’autres frameworks pour reprendre les commentaires d’un autre post) voire même très lourd : il suffit de voir le dossier app/cache pour s’en convaincre… Mais l’idée est plutôt d’utiliser un framework gérant l’ESI facilement.

      • Sébastien

        Pour Youporn, la performance, c’est surtout le fait qu’ils utilisent Redis comme seule base de données.

    • LoremIpsum

      Hmm… Quand on sait comment lui parler, Symfony devient performant.
      Quelques exemples de sites tournant sous Symfony2:
      – Dailymotion
      – Blablacar
      – Youporn

      Je pense qu’on peut dire que ce sont des sites à fort trafic, et en tout cas, ils ne sont pas dégueulasses en terme de temps de réponse 😉