Préparer son site Web à un pic de charge

de | 9 avril 2013

Ce billet traite d’une problématique que l’on a forcément rencontrée un jour dans sa vie d’internaute : lorsqu’une entreprise, avec un site web modeste passe à la télévision, cela se passe souvent en deux temps :

  1. Une belle URL passe à la TV
  2. Le site tombe

En effet, beaucoup de téléspectateurs, qui avec leur téléphone / tablette / ordinateur se connectent sur le site pour en savoir plus, créent un engorgement qui a souvent comme conséquence de rendre le site Web inaccessible ou de le mettre en erreur.

Il faut donc (quand on est au courant un peu à l’avance, bien sûr) anticiper un peu, car un site Web qui tombe, ce n’est quand même pas top ! L’objectif est donc de voir rapidement quelles sont les solutions on peut mettre en place. Il en existe des simples, des complexes, des coûteuses, certaines ne coûtent presque rien…

Nous allons donc faire trois suppositions :

  1. Vous êtes sur un hébergement mutualisé : bonne nouvelle, il y a des solutions ! La marge de manoeuvre est limitée, mais il y en a !
  2. Vous êtes sur un hébergement où vous êtes tout seul, en plus des solutions ci-dessus, d’autres permettent d’augmenter fortement le nombre d’internaute que l’on peut accueillir
  3. Vous utilisez PHP / MySQL : beaucoup, BEAUCOUP de sites utilisent PHP et MySQL. Même si certaines optimisations que je propose ne sont pas spécifiques PHP et / ou MySQL, certaines le sont et permettent d’améliorer l’efficience de manière significative.

 

1-Hébergement mutualisé

Cache applicatif

Si vous utilisez un CMS comme WordPress : utilisez le cache applicatif. Des plugin de cache tel que WP Super Cache existent. Ce cache permet d’éviter d’appeler les scripts PHP à chaque passage d’un utilisateur.

Le plugin permet en outre de se préparer à un pic de visites attendu en figeant le cache le temps du pic (les commentaires par exemple ne seront pas mis à jour tant que l’option sera activée)

Revue de code

Ce n’est pas l’objet de cet article, cependant, parfois une petite revue de code ne fait pas de mal. Cela peut être également l’occasion d’implémenter un cache directement dans le code comme dans cet exemple.

Cependant, cette option peut potentiellement s’avérer longue à mettre en place. Ce n’est peut être pas la meilleure chose à faire dans l’urgence !

Optimisation base de données

Si vous êtes sur un hébergement mutualisé, vous n’aurez certainement pas accès au log des requêtes lentes. Vous pouvez cependant l’activer sur un serveur chez vous, lancer un test de charge avec un outil comme Gatling. Vous serez alors en mesure d’identifier les requêtes lentes et de rajouter les index / modifier les requêtes.

2-Hébergement dédié

C’est quand même mieux quand on est chez soi, on peut changer ce que l’on veut ! Au passage, vu que l’on est libre, toutes les solutions pour un hébergement mutualisé sont valables pour un dédié, of course !

Dans ce qui suit, je liste des solutions (la liste n’est pas exhaustive, loin de là), de la plus facile à mettre en place à la plus couteuse / compliquée.

PHP : Installer APC ou Zend Optimizer

Ces extensions PHP sont font du cache d’opcode. Ils permettent d’améliorer de manière significative les temps d’exécution de scripts PHP en optimisant la compilation des pages.

Optimisation base de données

Vu que vous êtes sur une hébergement dédié, vous avez surement un accès SSH. C’est donc l’occasion de faire tourner un mysqltuner. MySQLTuner analyse l’utilisation de MySQL depuis que celui-ci est allumé. Il produit des préconisations d’optimisation (tuning) de configuration du serveur, dont la plupart sont à mettre en oeuvre dans le my.cnf

NGINX : l’autre serveur Web

NGINX est un serveur Web, au même titre qu’Apache ou IIs. Ce serveur est très utilisé dans le cadre d’architecture haute disponibilité.

NGINX possède aussi d’autres fonctionnalités telles que :

  • Reverse proxy
  • Load Balancer

L’avantage de ce serveur http est de travailler de manière asynchrone par un découpage des tâches, ce qui permet une meilleure consommation de ressource et des temps de réponse réduits. Contrairement à Apache, PHP n’est pas un module de NGINX. Il faut donc faire fonctionner PHP avec fastCGI comme le propose le site de Nginx.

Si cela vous fait un peu peur, vous pouvez au moins dans un premier temps :

  1. garder votre Apache que vous faites écouter sur le port 8080 (changer le LISTEN dans httpd.conf + changer dans le VHost)
  2. Mettre en place NGINX (sur le port 80) qui se chargera UNIQUEMENT des ressources statiques, comme montré dans cet exemple

 

Du cache avec Varnish

Varnish est un outil puissant permettant de mettre en cache les pages de votre site Web de manière très efficace. Installable sur votre serveur actuel (il suffit, un peu comme plus haut de faire écouter Varnish en 80 et Apache en 8080) Cela réclame un peu de configuration, afin de déterminer quelles pages doivent être mise en cache et celles qui ne doivent pas l’être.

A étudier donc si vous avez un peu de temps, et à tester auparavant (configuration, timeout de cache, invalidation sélective lors de la publication d’une page)…

Du load balancing avec par ex HA Proxy

HA Proxy est une des solutions de load balancing applicative disponible sur le marché. Pour ceux qui ne connaissent pas le concept, HA Proxy permet de répartir la charge sur plusieurs serveurs qui servent le même contenu.

C’est la solution la plus onéreuse puisqu’elle nécessite de mettre en place plusieurs serveur frontaux auxquels s’ajoutent le serveur qui accueillera HA Proxy lui-même. A réserver donc aux gens qui ont les moyens !

En conclusion

Il existe plein de solutions pour préparer son site à un gros pic de fréquentation, qu’il soit localisé dans le temps ou que cela se poursuive sur du long terme.

Bien évidemment, la liste des solutions proposées ci-dessus n’est pas exhaustive, bien au contraire, il faut bien garder à l’esprit l’objectif que l’on se fixe et garder un oeil sur son Google Analytics pour faire des prévision ! Avec un peu d’ingéniosité on arrive à booster de manière considérable son site Web…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Time limit is exhausted. Please reload the CAPTCHA.