Programando sem Deixar LOOP’s e SQL’s Prejudicarem a Performance da Aplicação
Dando continuidade ao assunto Performance da Aplicação, existem mais algumas regrinhas que costumamos utilizar para manter a boa performance:
NO-SUB-SELECT’s
Imagine que você escreva um SQL que possua um SUB-SELECT a ser executado para cada linha.
Algo do tipo:
SELECT
produto.nome AS nome,
( SELECT SUM(vendas.total)
FROM vendas
WHERE produto.id = vendas.id_produto ) as total_vendas
FROM produto
O que aconteceria neste caso?
O SELECT da cláusula WHERE seria executado para cada linha da tabela produto.
Se a tabela produto tiver 1.000 linhas, esta instrução SQL iria originar a execução de 1.001 requisições SQL’s, internamente.
Agora imagine 2, 5, 100, 1.000 usuários executando este SQL, simultaneamente.
Percebeu o peso que isto pode trazer para a aplicação?
1.000 usuários simultâneos é algo que faz parte da realidade da sua aplicação?
Um ataque DoS a esta página é algo possível?
A regra é evitar este tipo de SUB-SELECT.
Em geral, quando um SUB-SELECT destes for necessário, é sinal que você precisa de uma solução alternativa.
O mais comum é utilizarmos sumarizações.
No exemplo citado acima, criaríamos um Agendamento de Tarefa (a ser executado em horários específicos)
A rotina teria por finalidade calcular os totais de vendas e armazena-los em uma terceira tabela, apenas com as informações sumarizadas.
Assim a rotina buscaria os dados da tabela sumarizada por meio de um JOIN.
Normalmente, só utilizamos SUB-SELECT’s em SQL’s que resultem apenas uma ou pouquíssimas linhas.
NO-LONG-LOOP’s
Outro vilão da performance são os LOOP’s.
Imagine uma busca por produtos que resulte em centenas de resultados.
A programação exibe os resultados por meio de um LOOP que executa um bloco de código para cada produto.
Se o resultado contiver 200 produtos, seriam necessários 200 laços, ou seja, o mesmo bloco de código seria executado 200 vezes, em apenas uma requisição.
Dependendo do conteúdo do bloco, isto poderia trazer impactos negativos à performance.
A regra aqui é “paginação”.
Em geral, não há porque uma página permitir um retorno com mais de 20 ou 50 itens.
O vantagem é que o LOOP processará apenas 20 (ou 50) vezes o mesmo código (e não 1.000 vezes).
Melhor ainda, ele somente processará os 1.000 laços quando for necessário (a medida que o usuário for navegando pelas paginações).
Ronan Lucio Pereira
