Bonjour,
Question toute simple.
Je vois souvent dans les tutos sur le net pour les infras web distribuées qu'il est préconisé d'installer Memcached (ou Redis) pour améliorer les performances du backend.
Or y a t il un intérêt à installer Memcached si le développeur n'utilise pas explicitement les lib dans son code ?
Merci
# Re: De l'intérêt...
Posté par guitou . Évalué à 3.
Hello.
Pour memcached, c'est indépendant du code PHP:
PHP est un langage interprété et le lancement d'un script génère la transcription du code PHP en un code "intermédiaire" qui est éxécuté.
Ce sont ces fichiers intermédiaires que memcached met en cache, permettant ainsi une éxécution en moyenne plus rapide.
Donc sur un machine de dev, où le code changera très souvent, c'est sans intérêt (voire pénalisant selon la configuration du cache), mais sur un serveur de prod, c'est très utile en effet.
Pour redis, c'est plutôt à utiliser en remplacement/complément d'une DB classique: remplacement si tes seuls besoins peuvent se réduire à des couples clé/valeur, mais seulement en complément sinon (autrement dit, dès que tu as des relations entre des tables, autant bénéficier des fonctionnalités SQL).
Typiquement, tu peux gérer tes sessions avec une base redis, pour un accès plus rapide, une distribution plus transparente, et le reste de tes données avec un SGBDR classique mariadb+galera par exemple).
++
Gi)
[^] # Re: De l'intérêt...
Posté par jemore . Évalué à 2.
Memcached (le "D" pour "distribué") est un système de cache en mémoire, distribué entre plusieurs serveurs. A ma connaissance, il ne fait pas de cache de "code intermédiaire". C'est plutot les extensions OpCache ou APC qui s'en occupent.
L'interet d'un Memcached ou Redis est bien de faire du cache partagé et/ou distribué entre différents serveurs web. Si l'application le supporte, cela permet de mettre en cache des blocks de code HTML (ou du json, ou tout ce qu'on veut) plutot que de regenerer à chaque fois à partir des templates.
De plus, Redis/memcached fonctionnent tres bien pour faire du partage de sessions serveurs. En effet, en PHP, c'est une très mauvaise idée de partager les sessions entre plusieurs serveurs sur du NFS. En cas de forte charge, cela peut ralentir l'application. Alors que l'extension Redis pour PHP propose un handler de session qui fonctionne très bien même sous forte charge.
[^] # Re: De l'intérêt...
Posté par Kwiknclean . Évalué à 1.
Merci pour vos éclaircissement messieurs.
C'est tout à fait ma situation actuelle, et nous partageons les sources en NFS entre les deux noeuds (ils s'agit de projets Symphony).
Problème nous pour ce client des dizaines de projets (qui est un peu une cochonnerie car ça pond littéralement des millions de fichiers jusqu'a saturer les inodes disque avant de saturer la volumétrie).
Or ce dernier se plaint de performance certains appellent peuvent prendre jusqu’à plusieurs secondes pour répondre … je pense que je vais regarder du côté de memcached.
[^] # Re: De l'intérêt...
Posté par jemore . Évalué à 2.
Le code source PHP sur une baie NFS c'est aussi la cata. Il faut voir si tu peux activer un cache d'opcode (OpCache, APC) ca améliorera les perfo, mais ce n'est pas idéal. A moins d'activer les options "stats" (https://www.php.net/manual/en/apc.configuration.php#ini.apc.stat), ce qui limite les IO sur NFS (au détriment de la prise en compte des modifs).
[^] # Re: De l'intérêt...
Posté par Kwiknclean . Évalué à 1.
Super merci pour ces conseils.
Sinon pour se passer de NFS mais avoir plusieurs nodes qui ont le même code source, quelle solution ? Deployer les sources sur chaque noeud PHP ?
[^] # Re: De l'intérêt...
Posté par M.Poil (site web personnel) . Évalué à 1. Dernière modification le 18 octobre 2019 à 07:38.
Note que selon les cas, les latences induites par le réseau font que tu dégrades tes perfs en utilisant un Redis/Memcached sur une VM distante (Ce qui ne sera pas le cas en local)
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.