Optimisations apache/php/postgres pour site à haut volume – partie 2

Suite du post (situé ici), concernant la gestion des images.

Lorsque l’on diffuse un site, il existe divers éléments, certains dynamiques (des pages php), d’autres statiques (pages html ou des images). Ces dernières peuvent être mises en cache assez facilement par les navigateurs, et permettent une économie de bande passante et de ressources serveur. Afin d’optimiser tout ça, voici quelques pistes :

Création d’un sous-domaine "statique"

Si votre site est en www.monsite.com, tout votre contenu est sous cette racine. Si le virtualHost associé à ce site à la directive AllowOverride All, le serveur apache va chercher un fichier .htacess à chaque requête, y compris pour les images, ce qui est probablement inutile. Pour contrer cela, nous allons créer un sous domaine (par exemple static.monsite.com, les explications se trouvent ici) dans lequel nous allons poser toutes les images, et les autres éléments statiques. Dans les directives du VirtualHost, nous allons mettre la directive AllowOverride à none. Cela va déjà éviter de nombreuses requêtes.

Utilisation des ETags

Les ETags sont des tags véhiculés par le serveur au client, qui permettent de vérifier que le fichier n’a pas changé depuis la dernière fois. S’il n’a pas changé, on ne va pas plus loin et le client délivre le cache sans autre forme de procès. C’est difficilement envisageable sur des pages dynamiques, qui par définition changent très souvent. En revanche, sur un site très statique, ce tag prend une valeur très importante. On peut rajouter dans le VirtualHost défini précédemment la directive FileEtag Mtime Size pour que le serveur envoie ces tags au navigateur.

Attention, cette directive ne doit être utilisée que si votre site est diffusée par un seul serveur. Dans le cadre d’une diffusion en load balancing, on risque d’avoir au contraire une baisse notable des performances.

Conclusion

Cela demande à retravailler tout votre site, à remplacer les chemins des images et des pages statiques, et cela peut représenter un travail important. Toutefois, le gain est vraiment appréciable puisque vous servez les éléments statiques au mieux

One thought on “Optimisations apache/php/postgres pour site à haut volume – partie 2

Laisser un commentaire