Lecture 8 minutes

Dans notre article La web performance des projets Sylius, nous avons abordé l'importance de la web performance en e-commerce. Aussi, nous avons expliqué qu'il existe de nombreux indicateurs pour mesurer la performance de votre site e-commerce... Et autant de leviers pour l'optimiser ! Pour compléter ce sujet, nous vous présentons Varnish. Un précieux allié pour optimiser la performance de votre site Sylius via la mise en cache des données. C'était le sujet de notre présentation lors de la SyliusCon 2023.

Sylius et la mise en cache

Au même titre que toutes les autres solutions e-commerce, Sylius se doit d’être la plus performante possible. De par son socle technique léger basé sur Symfony, Sylius est déjà une solution nativement performante. En revanche, si votre site accueille un fort trafic, nous pouvons y apporter des améliorations notables. Pour cela, il existe plusieurs niveaux d’optimisation sur lesquels nous pouvons intervenir lors des développements.

Lorsqu’elles sont nombreuses, les requêtes en base de données sont le premier facteur de ralentissement de la génération des pages par le serveur. Grâce à Doctrine, l’ORM natif de Sylius, il est possible de mettre en place du cache le résultat des requêtes. Il est donc facile de mettre en cache les requêtes jouées très régulièrement, et dont le résultat change rarement. C’est souvent le cas du contenu de la page d’accueil des sites e-commerce par exemple.

Symfony dispose d’une abstraction permettant de mettre en place un cache applicatif facilement. Cela permet des mises en cache personnalisées, allant d’une réponse d’un service externe au bloc complet d’une page. Ce cache peut être stocké sur de nombreux supports via les Adapters proposés par Symfony. Cela va du stockage dans la mémoire PHP à l’utilisation de solutions spécialisées telles que Redis. L'avantage de cette dernière solution est que les données peuvent être partagées entre les différents serveurs. C’est pourquoi, chez Synolia, nous l’utilisons sur nos projets Sylius.

La mise en œuvre de ces deux niveaux de cache peut être chronophage et nécessite une bonne connaissance de l’application afin d’utiliser la bonne configuration sur le cache. D’autant plus qu’une question revient souvent : quelle doit être la durée du cache sur telle ou telle ressource ? Par simplicité, certains développeurs utilisent plus de serveurs pour multiplier les ressources. Mais cette solution n’est pas la bonne. Elle ne fait que déplacer le problème et augmente fortement le coût d’infrastructure et d'infogérance.

Présentation de Varnish

Dans la section précédente, nous avons vu comment mettre en place du cache au niveau de Sylius. Il est également possible de placer du cache à un niveau plus global, entre l’utilisateur et le serveur applicatif, c’est ce que nous appelons un serveur de cache HTTP. Ce serveur a pour seule mission de déterminer si la page demandée est déjà en cache ou non. Si c’est le cas, il renvoie la page. Sinon, le serveur applicatif est appelé pour renvoyer la page à l’utilisateur et la mettre en cache pour les prochains appels. Cette simplicité permet une réponse très rapide.

L’une des meilleures solutions proposées pour cela est Varnish. Elle remplit à merveille le rôle décrit précédemment en consommant peu de ressources serveur.

Les principaux avantages de Varnish, selon nous :

• Varnish tient très bien la charge. Même avec énormément de requêtes et de pages en cache, il est capable de répondre très rapidement en utilisant que peu de ressources serveur.
• Une fois la page en cache, Varnish la renvoie aux utilisateurs sans faire appel au serveur applicatif. Il est donc très adapté pour résister aux pics de trafic qui peuvent survenir sur un site e-commerce lors d’une opération commerciale ou une attaque DDOS.
• Lorsque la durée du cache est dépassée, Varnish peut continuer à envoyer la page en cache le temps de chargement de la nouvelle version sur le serveur applicatif. Ceci afin que les utilisateurs vivent une expérience optimale sans “attendre” la réponse. Ce mode est appelé le “grace mode” par Varnish. Il est configurable pour déterminer le temps après lequel la page n’est plus considérée comme pertinente et donc forcer l’appel au serveur applicatif (dans le cas d’une page appelée rarement par exemple).

Soyez attentifs aux points suivants :

• Varnish est programmable via un fichier de configuration en VCL, ce langage n’est pas commun, il peut donc être un frein au premier abord.
• Varnish ne supporte pas les appels en HTTPS, norme qui est aujourd'hui un prérequis pour tous les sites. Il faut donc avoir une solution en amont telle qu’un Load Balancer ou un Proxi, ou encore utiliser la version Entreprise de Varnish qui apporte également d’autres avantages.
• Enfin, il faut , comme pour tout système de mise en cache, définir une stratégie d’invalidation du cache. Que votre stratégie consiste en une simple valeur de TTL, une invalidation par clé de cache ou par Tags, Varnish saura répondre à vos attentes

Mise en place de Varnish sur un projet Sylius

La mise en cache des pages de votre site e-commerce Sylius

Comme tous les systèmes de cache, Varnish se base sur une clé de cache pour identifier la ressource en cache. Par défaut, Varnish se base sur l’url de la requête HTTP pour générer cette clé. Ceci est un gros avantage pour la mise en cache de sites e-commerce Sylius. La langue de l’utilisateur étant dans l’url, le cache est nativement distinct par langue.

Il est donc facile d’imaginer la mise en place de Varnish sur les pages Sylius telles que la page d’accueil, de listing produit, de produit, etc. Les pages du tunnel de commande et pages du compte utilisateur ne peuvent quant à elles pas être mises en cache aussi facilement. Mais nous verrons plus loin qu’il est possible de les rendre plus rapides.

Pour faire cela, la solution que nous proposons est de créer un Event Subscriber Symfony qui se place en dernière position de la réponse du Kernel. Il force les entêtes HTTP de la requête, selon si la page doit être mise en cache ou non.

La mise en cache spécifique à chaque utilisateur

À ce stade, le site n’est pas fonctionnel, car comme vous l’avez sûrement détecté, tous les utilisateurs partagent les mêmes pages mises en cache. La conséquence peut-être que, si nous nous concentrons sur la page d’accueil, tous les utilisateurs soient identifiés comme la première personne à demander la génération du cache. Tous les utilisateurs ont donc la même dénomination et le même mini-panier.

Afin de pallier cette problématique, Vanish met à disposition la mécanique des Edge Side Includes (ESI). L'objectif est de pouvoir délimiter un bloc de la page qui doit avoir une stratégie de cache différente. Dans notre cache, nous souhaitons que le bloc contenant le mini-panier ne soit pas mis en cache dans Varnish. Twig, le moteur de template de Sylius et les templates Sylius sont déjà compatibles avec ce changement. Il vous suffit de faire le changement suivant :

Comme nous venons de le voir, les ESI sont très faciles à mettre en place. Et ils répondent à beaucoup de problématiques. Toutefois, l'inconvénient principal est que Varnish attend la réponse de toutes les ESI de la page avant de répondre à l’utilisateur. Nous perdons donc en performance sur le TTFB. Une autre solution consiste à utiliser des appels API (ou Ajax) en Javascript pour récupérer les données spécifiques à l’utilisateur.

Quelques conseils en bonus

Nous ne pouvons finir sans vous donner quelques conseils qui vous feront gagner un temps précieux lors la mise en place de Varnish.

• Le premier est de rester vigilant sur les cookies que génèrent vos développements et les plugins Sylius que vous installez. Ceux-ci peuvent avoir des effets indésirables.
• Le second concerne également les cookies. Puisque Varnish est désactivé sur les requêtes qui contiennent des cookies, vous pouvez en créer sur votre navigateur pour bypasser le cache et faire vos tests.
• Un dernier conseil, et non des moindres... Lors de vos mises en production d’une nouvelle version du site, videz le cache et faites un script qui appellera les pages principales du site afin de préchauffer le cache sur ces pages avant même que les utilisateurs ne les visite. Grâce à cette astuce le TTFB sera toujours optimal.

Bien joué, vous avez optimisé votre site !