Eu acho que desde a atualização para o Magento 2.3.1 eu tenho problemas com o carregamento de páginas não armazenadas em cache (durante o desenvolvimento).
Eu fiz um rastreamento blackfire.io e verifica-se que 42 segundos são gastos em uso aqui .
Agora estou me perguntando qual é o objetivo disso. Acho que estou correndo em algum tipo de condição de corrida?
Alguém experimentou algo assim antes?
EDIT: A pilha de chamadas parece envolver o tradebug.
Respostas:
Bem, isso é uma escolha? - os engenheiros do Magento fizeram.
Isso não é uma resposta, mas parece que essa função aceita um retorno de chamada destinado a carregar dados em cache. O retorno de chamada verifica se existe atualmente um bloqueio. Caso contrário, ele coloca um bloqueio no lugar, carrega os dados e libera o bloqueio. Se houver um bloco no local, ele dorme por 100,000microssegundos (0,1 segundos) e depois chama o carregador novamente.
Então, pensando alto, meu palpite seria
O mecanismo lockedLoadData precisa diminuir a carga no servidor.
Anteriormente, quando o cache de configuração era limpo em sites carregados com oi, todos os clientes geravam as mesmas informações que aumentam significativamente a carga da CPU / io.
Com lockedLoadData, apenas um cliente gera cache e outros esperam por ele.
Mais detalhes sobre como ele funciona.
A primeira chamada de função "obtém dados" e, se obtém os dados, apenas os retorna (portanto, se houver dados no cache, o código funcionará como o anterior e não usará bloqueios).
Se os dados não estiverem disponíveis e o bloqueio estiver bloqueado, tentamos carregar os dados até que os dados cheguem ou o bloqueio seja removido.
Se não houver bloqueio, criamos um bloqueio e geramos dados, salve-o no cache e removemos o bloqueio e retornamos os dados
PS: Enviamos essas alterações como um patch para um dos clientes com carga de até 20kRPM e funciona por pelo menos três meses, sem nenhum problema. Talvez o problema na sua customização / módulos (por exemplo, se eles quebraram o mecanismo de cache)