J'utilise memcachepour le stockage de session et sur les pages de catégorie, j'ai remarqué dans de nouvelles transactions reliques où le démarrage de la session varien peut prendre plus de 30 secondes.
Cela peut être lié au verrouillage de session, mais je pensais que ce n'était pas vraiment un problème lors de l'utilisation de memcache.
N'importe qui a déjà fait face à cela ou a des idées sur ce qui pourrait en être la cause.
Réponses:
J'ai aussi beaucoup vu ça sur New Relic.
D'après ce que j'ai vu, il y a plusieurs causes différentes, je n'ai pas une compréhension complète de ce problème, mais c'est quelque chose que j'ai étudié récemment. Voici mes conclusions.
Chaque action de contrôleur dans Magento utilise la session, que cela soit nécessaire ou non. La session est instanciée avec impatience dans Mage_Core_Controller_Varien_Action :: preDispatch
Si le verrouillage de session est activé, cela signifie que pendant la durée de la demande, votre session est verrouillée jusqu'à la fin de la demande. Je n'ai pas encore trouvé le morceau de code qui libère le verrou de session, mais je suis presque sûr qu'il se trouve quelque part.
En fin de compte, cela signifie que si vous envoyez plusieurs demandes simultanées aux actions du contrôleur Magento à partir du même emplacement en utilisant la même session, vous devrez attendre que certaines de ces demandes soient terminées et déverrouiller la session pour continuer. Je vois généralement cela comme une transaction lente sur une nouvelle relique bloquée Mage_Core_Model_Session_Abstract_Varien::startpendant environ 30 secondes (le délai d'attente du verrouillage de session, je pense).
Ce rapport sur New Relic a plusieurs inconvénients comme je le vois
J'ai vu quelques causes communes à cela, pas une liste définitive par tous les moyens
Des robots comme Baidu et Yandex étant un peu désagréables et battant le site Web. Ils sont exécutés à partir d'un emplacement, tirant de nombreuses demandes, utilisant la même session et déclenchant le mécanisme de verrouillage de session, montrant ainsi des transactions lentes dans New Relic.
Avec les sites Web vernis, les données spécifiques au client doivent être chargées avec soin, certains sites Web gèrent cela en utilisant des appels ajax vers le backend Magento pour obtenir les données requises. J'ai également vu certains sites Web utiliser des appels ajax vers le backend pour obtenir des informations spécifiques au produit, telles que le montant restant en stock lorsqu'un article est en vente.
Si une seule page déclenche plusieurs appels ajax vers le backend lors du chargement de la page, elle peut potentiellement déclencher le mécanisme de verrouillage de session. Plus le nombre de rappels ajax vers le backend Magento est élevé, plus vous risquez de rencontrer un verrouillage.
La même chose que ci-dessus vraiment, sauf qu'au lieu d'utiliser des appels ajax, il utilise Edge Side Include qui semble être de nouveaux appels vers le backend.
Je n'ai pas encore réagi, c'est donc purement théorique, mais c'est quelque chose que j'envisage de faire au cours des prochains mois.
J'ai soulevé ce problème lors de la conférence Mage Titans UK 2016 et Fabrizio Branca m'a dirigé vers le module suivant: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Basé sur une expression régulière, le module empêchera les bots de créer de vraies sessions, cela devrait avoir l'avantage qu'aucun verrou de session ne sera atteint, et que vos ressources de session ne seront pas battues par des bots grossiers. Les bots ne devraient plus polluer vos lectures New Relic.
Pour les appels ajax / ESI pour obtenir les données des clients sur les pages en cache, je ne vois rien que vous puissiez faire. Vous devez avoir accès à la session afin de récupérer des données spécifiques au client.
Cependant , pour les appels ajax / ESI pour obtenir des données spécifiques au catalogue (comme un stock limité), je ne vois pas du tout besoin d'une session pour exister sur cette demande. Mon plan pour l'avenir est de tester une extension du Aoe_BlackHoleSessionmodule afin de pouvoir cloisonner les demandes vers une URL spécifique comme étant sans session.
Je connais moins bien les composants internes d'ESI, donc malheureusement je n'ai pas grand-chose à ajouter là-dessus.
Lors de la conférence, Fabrizio Branca a déclaré qu'il était capable de désactiver complètement le verrouillage de session sans aucun effet indésirable, testez à vos propres risques.