Um painel de filtros que demora quatro segundos a responder é percebido como partido. O problema raramente é o módulo em si: vem da forma como as consultas são construídas e do que a base de dados tem de percorrer para lhes responder.
Aqui fica como localizar a causa antes de mudar o que quer que seja.
Medir antes de supor
Três registos, por esta ordem.
O tempo de resposta real de uma consulta de filtragem, medido no separador de rede do navegador na sua maior categoria com dois ou três filtros ativos. Anote o valor: é o seu ponto de partida.
A parte desse tempo passada na base de dados. Ative o perfilamento do PrestaShop em ambiente de teste: mostra o número de consultas executadas e a duração acumulada. Se o tempo de base representar 80 % do total, não vale a pena olhar para outro lado.
O número de consultas executadas. É muitas vezes a revelação: uma página de categoria filtrada que executa trezentas consultas tem um problema de conceção, não de potência de servidor.
Este terceiro ponto merece atenção. Uma multiplicação das consultas assinala geralmente um cálculo de contadores valor a valor, ou um carregamento de produtos um a um dentro de um ciclo.
As quatro causas principais
As junções nas tabelas de atributos. Filtrar por três atributos exige juntar várias vezes as tabelas de valores. Num catálogo de vinte mil combinações, essas junções produzem conjuntos intermédios consideráveis.
O cálculo dos contadores. Mostrar o número de resultados atrás de cada valor exige uma agregação por valor. Num painel com sessenta valores, isso pode dar sessenta agregações em cada mudança de seleção.
A contagem total para a paginação. Contar as linhas de uma seleção larga custa quase tanto como lê-las.
Os índices em falta. Nas tabelas de ligação entre produtos, atributos e categorias, um índice ausente transforma uma pesquisa num percurso completo da tabela.
Diagnosticar os índices
É a verificação mais rentável e mais rápida.
Recupere a consulta de filtragem mais lenta a partir do registo de consultas lentas da sua base, e execute-a precedida da palavra-chave de explicação do plano de execução.
Três sinais a identificar no resultado.
Um tipo de acesso que indica um percurso completo numa tabela volumosa. É sinal de índice em falta ou inutilizável.
Um número de linhas examinadas sem relação com o número de linhas devolvidas. Examinar duzentas mil linhas para devolver quarenta indica que a filtragem se faz depois da leitura em vez de por índice.
A menção de uma ordenação temporária ou de uma tabela temporária, que assinala que a base não consegue satisfazer a ordenação por índice e tem de materializar um resultado intermédio.
Ponto prático: os índices úteis nestas tabelas incidem muitas vezes sobre colunas combinadas, e a ordem conta. Um índice sobre produto e depois atributo não serve as mesmas consultas que um índice sobre atributo e depois produto.
Filtros por Facetas AJAX PrestaShopA navegação por facetas que filtra depressa e indexa como deve ser99,00€
Reduzir o trabalho em vez de o acelerar
Antes da otimização técnica, três decisões funcionais têm muitas vezes mais efeito.
Reduzir o número de filtros. Cada atributo filtrável acrescenta junções potenciais e contadores a calcular. Doze filtros dos quais quatro são usados custam três vezes demais.
Prescindir dos contadores nos catálogos grandes, ou calculá-los apenas nos filtros mais usados. O conforto perdido é real, o ganho de tempo também.
Limitar a profundidade de combinação. Acima de três filtros em simultâneo, as seleções tornam-se raras e caras. Pode pôr um teto sem que ninguém dê por isso.
Estas três medidas não exigem desenvolvimento nenhum e testam-se numa tarde.
O índice dedicado
Quando as medidas anteriores não chegam, a resposta estrutural consiste em deixar de consultar as tabelas de catálogo no momento da filtragem.
O princípio: uma tabela plana, pré-calculada, com os valores filtráveis de cada produto, o preço, a disponibilidade e as categorias. A filtragem passa a ser uma consulta simples sobre uma única tabela indexada.
Três pontos de implementação.
A atualização tem de disparar em cada alteração de produto, de preço ou de stock. Um índice dessincronizado mostra produtos que já não existem ou esconde novidades.
A reconstrução completa tem de continuar possível, e o seu tempo de execução medido: num catálogo grande, pode demorar vários minutos e não deve correr em hora de ponta.
O disparo em massa. Uma importação de catálogo que altera dez mil produtos não deve desencadear dez mil reconstruções unitárias. Preveja um modo diferido.
A cache, e os seus limites
A cache é útil e é muitas vezes mal usada neste assunto.
Guardar em cache os resultados de filtragem funciona bem quando as combinações pedidas são poucas e repetidas. É o caso na maioria das lojas: algumas dezenas de combinações cobrem o essencial do tráfego.
Dois limites a conhecer. A cache não trata a primeira visita de cada combinação, que continua lenta. E tem de ser invalidada em cada mudança de stock ou de preço, senão mostra informação falsa.
Nos dados de disponibilidade, a duração da cache tem de ficar curta, alguns minutos, o que reduz bastante o seu interesse. Uma abordagem comum é guardar em cache a lista dos produtos correspondentes e ir buscar preço e stock em direto.
As verificações do lado da infraestrutura
Três pontos que não dependem do código.
A memória atribuída à base de dados. Uma base que não consegue manter os índices em memória vai relê-los ao disco em cada consulta. É a causa mais frequente de lentidão generalizada depois de um crescimento de catálogo.
A configuração da cache de consultas e dos buffers, a ajustar à dimensão real dos seus dados em vez de ficar nos valores por defeito da instalação.
Os recursos concorrentes. Uma exportação de catálogo ou uma tarefa agendada que corre ao mesmo tempo que o pico de tráfego degrada tudo. Desloque o que puder ser deslocado.
A abordagem completa
Seis etapas, por ordem decrescente de rentabilidade.
1. Meça o tempo de resposta e o número de consultas.
2. Verifique os índices com um plano de execução sobre a consulta mais lenta.
3. Reduza o número de filtros propostos aos que são realmente usados.
4. Desative ou limite os contadores se o catálogo for grande.
5. Ponha uma cache sobre as combinações frequentes.
6. Pondere um índice dedicado se as cinco primeiras etapas não chegarem.
Ponto de método: meça depois de cada etapa. Avançar várias etapas de uma vez tira-lhe a possibilidade de saber qual produziu o efeito, e portanto de saber onde concentrar o esforço da próxima vez.
O módulo Filtros por Facetas AJAX para PrestaShop integra estes mecanismos no PrestaShop 8 e 9: índice dedicado pré-calculado com atualização incremental, contadores de resultados em agregação única, cache por combinação com invalidação nas mudanças de stock e de preço, e limitação configurável da profundidade de combinação.
