Estoy usando el memcachealmacenamiento de sesión y en las páginas de categoría que he notado en nuevas transacciones de reliquia donde el inicio de sesión variable puede tomar más de 30 segundos.
Posiblemente pueda tener algo que ver con el bloqueo de la sesión, pero pensé que esto no era realmente un problema al usar memcache.
Alguien alguna vez se enfrentó a esto o tuvo ideas de lo que podría estar causando esto.
Respuestas:
También he visto mucho en New Relic.
Por lo que he visto, hay algunas causas diferentes, no tengo una comprensión completa de este problema, pero es algo que he estado investigando recientemente. Aquí están mis hallazgos.
Cada acción del controlador en Magento usa la sesión, ya sea que la necesite o no. La sesión se instancia con entusiasmo en Mage_Core_Controller_Varien_Action :: preDispatch
Si tiene habilitado el bloqueo de sesión, esto significa que durante la duración de la solicitud, su sesión estará bloqueada hasta que se complete la solicitud. Todavía no he encontrado el código que libera el bloqueo de sesión, pero estoy bastante seguro de que está allí en alguna parte.
En última instancia, esto significa que si dispara múltiples solicitudes simultáneas a las acciones del controlador Magento desde una ubicación usando la misma sesión, tendrá que esperar a que se completen algunas de esas solicitudes y desbloquear la sesión para continuar. Por lo general, veo esto como una transacción lenta en una nueva reliquia atascada Mage_Core_Model_Session_Abstract_Varien::startdurante ~ 30 segundos (creo que el tiempo de espera de bloqueo de sesión).
Este informe sobre New Relic tiene múltiples desventajas tal como lo veo
He visto algunas causas comunes para esto, no una lista definitiva de ninguna manera
Los rastreadores como Baidu y Yandex son un poco groseros y maltratan el sitio web. Se ejecutan desde una ubicación disparando numerosas solicitudes, utilizando la misma sesión y activando el mecanismo de bloqueo de la sesión, por lo tanto, muestran transacciones lentas en New Relic.
Con los sitios web barnizados, los datos específicos del cliente deben cargarse con cuidado, algunos sitios web manejan esto mediante llamadas ajax al servidor de Magento para obtener los datos requeridos. También he visto algunos sitios web que utilizan llamadas ajax al back-end para obtener información específica del producto, como la cantidad que queda en stock cuando un artículo está en oferta.
Si una sola página desencadena múltiples llamadas ajax al backend en la carga de la página, potencialmente puede desencadenar el mecanismo de bloqueo de la sesión. Mientras más llamadas ajax se realicen al backend de Magento, es más probable que experimente un bloqueo.
Realmente es lo mismo que el anterior, excepto que en lugar de usar llamadas ajax, utiliza Edge Side incluye que parecen ser nuevas llamadas al backend.
Todavía no he actuado esto, así que todavía es puramente teórico, pero es algo que estoy pensando hacer en los próximos meses.
Mencioné este problema durante la conferencia Mage Titans UK 2016 y Fabrizio Branca me señaló el siguiente módulo: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Basado en una expresión regular, el módulo evitará que los Bots creen sesiones reales, esto debería tener el beneficio de que no se golpeará el bloqueo de la sesión y que los recursos de la sesión no serán maltratados por bots groseros. Los bots ya no deberían contaminar tus lecturas de New Relic.
Para las llamadas ajax / ESI para obtener datos de clientes allí en páginas en caché, no hay nada que pueda hacer que yo pueda ver. Necesita acceso a la sesión para recuperar datos específicos del cliente.
Sin embargo , para las llamadas ajax / ESI para obtener datos específicos del catálogo (como existencias limitadas), no veo ninguna necesidad de que exista una sesión en esa solicitud. Mi plan para el futuro es probar una extensión del Aoe_BlackHoleSessionmódulo para poder desviar las solicitudes a una URL específica como sin sesión.
Estoy menos familiarizado con los aspectos internos de ESI, así que lamentablemente no tengo mucho que comentar allí.
Durante la conferencia, Fabrizio Branca dijo que fue capaz de desactivar el bloqueo de sesión por completo sin ningún efecto negativo, prueba bajo su propio riesgo.