Estou usando o memcachearmazenamento de sessões e nas páginas de categorias que notei em novas transações de relíquias nas quais o início de várias sessões pode levar mais de 30 segundos.
Pode ser algo relacionado ao bloqueio de sessão, mas achei que isso não era realmente um problema ao usar o memcache.
Alguém já enfrentou isso ou tem idéias do que poderia estar causando isso.
Respostas:
Eu já vi isso bastante na New Relic também.
Pelo que vi, existem algumas causas diferentes, não tenho um entendimento completo desse problema, mas é algo que venho investigando recentemente. Aqui estão as minhas descobertas.
Toda ação do controlador no Magento usa a sessão, se é necessário ou não. A sessão é instanciada avidamente em Mage_Core_Controller_Varien_Action :: preDispatch
Se você tiver o bloqueio de sessão ativado, isso significa que, durante a solicitação, sua sessão será bloqueada até que a solicitação seja concluída. Ainda não encontrei o código que libera o bloqueio da sessão, mas tenho certeza de que está em algum lugar.
Por fim, isso significa que, se você disparar várias solicitações simultâneas para ações do controlador Magento a partir de um único local usando a mesma sessão, terá que aguardar que algumas dessas solicitações sejam concluídas e desbloqueie a sessão para continuar. Normalmente, vejo isso como uma transação lenta na nova relíquia travada Mage_Core_Model_Session_Abstract_Varien::startpor ~ 30 segundos (acho que o tempo limite de espera da trava de sessão).
Este relatório da New Relic tem várias desvantagens, a meu ver
Vi algumas causas comuns para isso, e não uma lista definitiva por qualquer meio
Rastreadores como o Baidu e o Yandex são um tanto rudes e prejudicam o site. Eles estão sendo executados em um local disparando várias solicitações, usando a mesma sessão e ativando o mecanismo de bloqueio de sessões, mostrando transações lentas na New Relic.
Com sites envernizados, os dados específicos do cliente devem ser carregados com cuidado, alguns sites gerenciam isso usando chamadas ajax para o back-end do Magento para obter os dados necessários. Também vi alguns sites usando chamadas ajax para o back-end para obter informações específicas do produto, como o valor restante em estoque quando um item está à venda.
Se uma única página acionar várias chamadas ajax para o back-end no carregamento da página, poderá potencialmente acionar o mecanismo de bloqueio de sessão. Quanto mais o ajax ligar de volta para o back-end do Magento, maior a probabilidade de você experimentar o bloqueio.
O mesmo que acima, na verdade, exceto que, em vez de usar chamadas ajax, ele usa Edge Side Include, que parecem ser novas chamadas para o back-end.
Ainda não tomei uma atitude, por isso ainda é puramente teórico, mas é algo que pretendo fazer nos próximos meses.
Eu trouxe esse problema à tona durante a conferência Mage Titans UK 2016 e Fabrizio Branca me indicou o seguinte módulo: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Com base em uma expressão regular, o módulo impedirá que os Bots criem sessões reais, isso deve ter o benefício de que nenhum bloqueio de sessão será atingido e que seus recursos de sessão não serão prejudicados por bots rudes. Os robôs não devem mais poluir suas leituras da New Relic.
Para chamadas ajax / ESI para obter dados de clientes em páginas em cache, não há nada que você possa fazer que eu possa ver. Você precisa acessar a sessão para recuperar dados específicos do cliente.
No entanto , para chamadas ajax / ESI para obter dados específicos do catálogo (como estoque limitado), não vejo a necessidade de uma sessão para essa solicitação. Meu plano para o futuro é testar uma extensão do Aoe_BlackHoleSessionmódulo para que eu possa isolar solicitações para um URL específico como estando sem sessão.
Estou menos familiarizado com os internos da ESI, então, infelizmente, não tenho muito o que comentar por lá.
Durante a conferência, Fabrizio Branca disse que foi capaz de desativar completamente o bloqueio de sessão sem efeitos negativos, teste por sua conta e risco.