le-phare / le-phare.github.io

The Faros site
https://faros.lephare.com
4 stars 2 forks source link

increase default realpath_cache_ttl #121

Open pierreboissinot opened 9 months ago

pierreboissinot commented 9 months ago

Problème

Il semble qu'à cause du symlink fait lors d'un déploiement, nous bridons le realpath_cache_ttl à 60, ce qui n'est pas assez pour une app Symfony.

realpath_cache_ttl is set to 60 but Symfony recommends at least 120.

Note: lors d'un déploiement, le cachetool clearstatcache(true) avant le changement de symlink.

Analyse de solution

Il me semble que ce setting ait été défini à 60 car ce cache n'est pas partagé mais relatif aux workers PHP-FPM. Réduire le TTL est donc un hack pour s'assurer que le file stat cache soit cleared pour chaque worker après un déploiement.

Note that, unlike APCu and Opcache, the file status cache is per-process rather than stored in shared memory. This means that running stat:clear against PHP-FPM will only affect whichever FPM worker responds to the request, not the whole pool. Julien Pauli has written a post with more details on how the file status cache operates.

https://github.com/gordalina/cachetool#cachetool---manage-cache-in-the-cli

Afin de ne pas impacter les perfs d'une app Symfony à cause de notre process de déploiement, nous devrions étudier la solution recommendée par Julien Pauli:

What I find beeing the best solution for deployment to prevent this uncool mechanism to happen, is to prepare a totally new PHP worker pool, and load balance your FastCgi Handler onto it, giving up with the old one when all old workers have finished.

Cela n'est pas une mince affaire, peut-être que rappeler le cachetool stat:clear après que le symlink soit changé suffirait ?