domingo, 2 de dezembro de 2012

Eis o grande segredo...

Hoje vou falar sobre uma das formas mais eficazes de otimização de qualquer sistema web: Apresento-lhes o "Cache de Queries".

No post anterior, discerni sobre a importância da otimização do banco de dados e sobre a preocupação que se deve ter com o tempo de execução de cada uma das queries que fazem parte de um sistema.

Portanto, o banco de dados é o ponto de maior geração indireta de gargalos em um sistema web. Se ele estiver lento, todo o resto ficará lento, através de um efeito cascata. O acesso ao banco é o maior problema.

Vamos então "eliminar o problema".

"Mas como assim? Afinal o banco de dados é o cerne do sistema. Sem ele não faria sentido o sistema!" - já ouço o leitor retrucar.

Na verdade, não estamos falando, obviamente, em eliminar o banco de dados. Estamos falando em evitá-lo o máximo que pudermos!

Quanto menor for o número de vezes que a aplicação precisar "encostar" no banco de dados, melhor para a performance geral do sistema web.

E é isso exatamente o que faz o Cache de Queries! Evita "idas" desnecessárias ao banco de dados!

O Cache de Queries é algo realmente modificador de vidas. Eu diria que um sistema pode ser dividido entre antes e depois da implementação de Cache de Queries.

O Cache de Queries funciona da seguinte maneira: Você especifica deliberadamente que uma determinada query SQL será "cacheada", isto é, posta em memória real. Então, na primeira vez que a query é executada, o servidor de aplicação efetivamente requisita a consulta ao banco de dados. Entretanto, o resultado de retorno dessa consulta, ou seja o recordset obtido em resposta, é armazenado em memória no servidor de aplicação. Isso significa dizer que, a partir deste momento, se algum usuário requisitar novamente essa mesma query, o banco de dados não será mais incomodado.

O que posso dizer é que o aumento de performance com a técnica é gritante.

As medições de antes e depois da implementação de Cache de Queries mostram situações em que o tempo de carga total de uma página com a query cai de 1 ou 2 segundos para ZERO. É óbvio que algum tempo é gasto no processo para recuperar os dados, ainda que estejam em memória. Mas como a unidade de medida é o milissegundo, o que o servidor de aplicação nos diz é que o tempo gasto foi de zero milissegundos, ou seja, a consulta levou menos de 1 milissegundo para ser executada!

"Uau! Vamos então cachear todas as queries do sistema e resolver todos os nossos problemas!"

Não é bem assim... Há situações que não permitem que uma query seja cacheada. Há de se analisar query por query do sistema, e definir quais delas são elegíveis para o cache. Vamos supor, por exemplo, que o resultado de uma pesquisa dependa de dados que estejam sendo alimentados pelo usuário do sistema. Para ilustrar: Suponha que se esteja pesquisando um aluno pelo seu nome, em uma lista de alunos inscritos. Se é um sistema de inscrição de alunos, e se pusérmos o retorno da pesquisa em cache, alunos inscritos posteriormente ao cacheamento não aparecerão no resultado da pesquisa.
 
Além disso, lembrando de nosso amigo Lavoisier, se ganhamos de um lado, perdemos de outro. Nesse contexto que estamos trabalhando, o ganho é de extraordinária performance. Em detrimento de um uso maior de memória real no servidor de aplicação.

Como sempre, é um ajuste fino. Há que ser estudado com cautela. Mas, como sempre, a relação custo x benefício é positiva.

As linguagens em geral, permitem também, que seja especificado quanto tempo a query ficará em cache, em segundos, minutos, horas ou dias. O resultado de certas queries podem ficar "eternamente" (365 dias) em cache. Por exemplo, no contexto da educação, a query que retorna as séries em determinado ano letivo é uma delas. Como a única chance de ser criada uma série nova é na virada do ano, então a lista das séries pode ficar o ano inteiro em cache.

A conclusão é que, um sistema que não usa cache de queries está aquém do desejado e vai sofrer com certeza, de lentidão, quiçá terá comprometido seu uptime.

Minha opinião pessoal é que todo sistema deve ser desenvolvido com esta técnica desde o princípio, em função dos resultados excepcionais alcançados para o usuário final.
 
No próximo post o assunto será algo igualmente importante: O time-out de queries! Até lá.

Nenhum comentário:

Postar um comentário