Temps de réponse long pour Mage_Core_Model_Session_Abstract_Varien :: start

15

J'ai donc remarqué dans New Relic sur beaucoup de nos sites, beaucoup de longs chargements de pages se produisent en raison de Mage_Core_Model_Session_Abstract_Varien :: start. J'ai fait des recherches et je n'ai pas vraiment vu quelqu'un d'autre en parler.

Nous utilisons Nginx, PHP FPM, Redis pour la mise en cache et Memcache pour les sessions. Certaines de mes idées sont que c'est peut-être quelque chose d'autre qui prend une éternité et il semble que le chargement de la session soit le problème. Ou d'une manière ou d'une autre, un code personnalisé ajoute de nombreuses données à la session, ce qui provoque d'énormes sessions.

Je ne suis pas très bien informé en termes de sessions et comment elles sont gérées, mais j'ai trouvé quelques articles parlant du verrouillage de session. Cependant, je ne pense pas que les gens ouvriraient autant de pages en même temps.

Certaines de ces charges sont de 20 à 30 secondes. Je suis simplement curieux de savoir si quelqu'un d'autre a remarqué cela ou avait plus de connaissances sur la façon d'analyser ces types de longues demandes en raison des sessions.

performance session dan.codes
la source
1
J'ai remarqué le même comportement avec Redis utilisé comme stockage de session. Aucun indice pourquoi cela se produit non plus.
2
Avez-vous déjà pu en trouver la cause? J'ai une configuration très similaire (Redis pour le cache, memcached pour les sessions) et nous avons récemment commencé à utiliser New Relic pour suivre les performances. Nous attrapons plus de 20 secondes de traces qui semblent être causées par quelque chose dans MCMSAV :: start comme vous le voyiez. Malheureusement, je ne peux pas voir plus profondément, une info-bulle indique "Une visibilité plus approfondie n'est pas disponible car ces classes et méthodes ne sont pas instrumentées avec la configuration actuelle de l'agent PHP". Je dois encore enquêter davantage. Des idées?
BrianVPS
1
@BrianVPS Je n'ai jamais rien trouvé. Cela reste un mystère pour moi et je n'ai jamais eu plus de temps pour le retrouver. Je le vois toujours dans chaque projet. Avez-vous déjà trouvé quelque chose?
dan.codes
1
Je ne sais pas si nous avons trouvé des causes, mais je ne l'ai pas vu récemment. Nous avons apporté des modifications importantes au site et coupé beaucoup de graisse. J'ai désactivé certains modules de base inutilisés, supprimé une tonne d'attributs, de catégories et de produits inutilisés. Depuis lors, les choses se sont améliorées sur tous les fronts. Je ne sais pas si tout cela était lié, mais en général, se débarrasser de choses inutiles semble aider Magento de manière significative. C'est un système puissant, mais gonflé avec beaucoup de code dont de nombreux sites n'ont pas besoin. Se débarrasser de l'excès est très utile.
BrianVPS
@BrianVPS J'ai exactement le même problème que vous aviez (20+ secondes de traces qui semblent être causées par quelque chose dans MCMSAV :: start). Avez-vous trouvé une solution?
Denis Spalenza

Réponses:

7

Ceci est probablement lié à un phénomène concernant les sessions du système de fichiers. Malgré ce que vous signalez via l'utilisation de Mecached pour les sessions, je ne l'ai vu moi-même que lorsque j'utilisais un système de fichiers.

Cela a déjà été abordé ici:

/magento//a/3721/336

En fait, une capture d'écran d'un cachegrind révèle le moment exact où le démarrage de la session prend un temps excessif, Mage_Core_Model_Session_Abstract_Varien::startcomme vous l'avez correctement souligné:

entrez la description de l'image ici

Dans le fil référencé, il a été suggéré que cet effet puisse être atténué avec un stockage de session en mémoire - mais aucune donnée concrète n'existe à ma connaissance pour soutenir la théorie. Si vous utilisez en fait memcached, il va de soi que le verrou de session de niveau PHP empêcherait les demandes futures au stockage de session d'être accordées jusqu'à ce que le verrou soit libéré.

En général, cela n'est généralement visible que sur les demandes nécessitant l'accès aux informations de session, donc l'architecture de votre thème frontal sera bénéfique pour limiter la quantité d'accès nécessaire pour éviter les verrous potentiels lorsqu'un utilisateur a un autre onglet ou une autre demande de longue durée en cours lors de la décision. déménager.

HTH, Santé.

philwinkle
la source