Juste un billet rapide en espérant qu'un jour quelqu'un sera heureux de trouver ici ce que je n'ai pas pu trouver sur Internet.
J'ai amené Symfony dans mon entreprise il y a 3 ans maintenant et presque tous nos projets tournent avec. Pourtant, la gestion de la cache a toujours été un cauchemar.
Comme sûrement beaucoup de sites à gros trafic, nous travaillons avec des grappes de frontaux Web raccordés à un serveur NFS afin de distribuer les sources PHP.
Nous avons vite compris que mettre la cache Symfony sur un montage NFS était de la folie et c'est avec joie que nous avons accueilli l'arrivée de Symfony 1.1 et sa configuration du répertoire de cache, mais depuis, chaque "symfony cc" restait un moment délicat car il arrivait régulièrement qu'un serveur ne reconstruise pas sa cache correctement ... et là, la page blanche, des alertes partout et des développeurs en train de faire des cc frénétiquement en surveillant la porte du patron.
Chose étrange, personne ne semble avoir le même problème, je me permets donc de contacter directement Sensio Labs (éditeur du Framework) qui m'explique que même en dehors de la cache, Symfony n'aime pas NFS et que pour une solution, il fallait mieux contacter leur service commercial (sic ... mais je ne peux pas leur en vouloir :)). Je m'exécute donc et, dans l'urgence, je me débarrasse de nos serveurs NFS ... c'est mieux, mais la cache continue de temps en temps à nous faire peur.
C'est seulement cette semaine, dans une ultime tentative, que je m'attaque à notre cache OPCODE : Xcache.
Il y a quelques années, Xcache était la référence de la cache OPCODE, rapide, simple, stable. Mais depuis, il faut l'avouer, le projet n'a pas vraiment évolué, pris de vitesse par APC qui s'impose aujourd'hui comme la solution de référence.
Avec APC, le miracle s'accomplit, j'ai beau faire des cc en masse, rien ne semble altérer la stabilité de notre application malgré des centaines de hits client.
Mais la véritable surprise, ce sont les performances : 30% de gain sur nos graphes CPU, il était vraiment temps de changer.
Conclusion, pour vos projets Symfony, oubliez NFS, copiez vos sources en local sur cache machine, oubliez Xcache, utilisez APC !
Et pour les curieux, voici la configuration APC retenue :
[apc] apc.enabled=1 ; 1 segments of 60Mo apc.shm_segments=1 apc.shm_size=60 ; No optimization apc.optimization=0 ; Never expire apc.ttl=0 apc.user_ttl=0 ; workaround for CLI apc.enable_cli=1 ; Symfony make lot of path lookups, try to optimize apc.include_once_override=1 apc.canonicalize=1 ; Wait 2 seconds to rebuild cache apc.file_update_protection=2
Comments (4)
Effectivement APC est une excellente solution. On pourrait presque mettre le répertoire de cache Sf sur un Ramdisk, je n'ai pas testé avec Symfony mais avec d'autres applications, ça marche plutôt pas mal.
Une petite question cependant, comme vous n'utilisez plus NFS, vous déployez votre application comment sur la grappe de serveurs ? Et pour chaque mise à jour majeure ?
Cordialement :)
Attention cependant de bien faire un apc_clear_cache() lors des mises en prod sinon le nouveau code PhP déployé n'est pas pris en compte.
La surcharge de la tâche de déploiement de symfony est une bonne idée par exemple :
http://blog.akei.com/post/630818320/taches-de-deploiement-specifiques-avec-sy...
Sinon pour le cache de partials dès qu'on a une ferme de frontaux web le changement de quelques lignes dans le factories.yml pour utiliser sfMemcacheCache est aussi une bonne chose.
Pour finir php5.3 est arrivé à maturité, il est temps d'y passer les économies de mémoire et de ressources CPU sont intéressants en attendant entres autres doctrine2.
Et puis : basta la vista NFS !
Pour la réplication, je passe maintenant par un script PHP en sur-couche de Phing, ça marche très bien, je vais surement faire un billet dessus.
@Sébastien: Oui, je le connais le coup du stat=0, mais j'ai toujours un peu de mal avec depuis le jour où on a passé une heure à chercher pourquoi la réplication ne marchait pas alors que c'était juste l'OPCODE qui se mettait pas à jour. Je préfère encore faire confiance à une bonne gestion des fstat() par le Kernel.
Leave a comment...