Há uns tempos comecei a fazer uma análise mais aprofundada da performance dos sites que gerimos aqui no trabalho. Essencialmente pretendemos saber qual a evolução ao longo dos últimos meses, procurar padrões e tentar encontrar explicações para eventuais problemas e as respectivas soluções. O processo que seguimos pode ser interessante para mais pessoas, por isso vou fazer aqui uma pequena descrição daquele.
Inicialmente fomos analisar a performance dos sites. Utilizámos uma aplicação que analisa logs de sites e analisámos alguns dados dos últimos três meses:
Com estes dados pretendemos detectar padrões anormais e tendências:
- Se os tempos de resposta se mantiveram e as page views têm subido, é sinal que o site escala. Se os tempos de resposta aumentam exponencialmente, temos problemas.
- Temos picos de erros em determinado dias? Então esses dias devem ser investigados no caso de não terem sido detectados problemas na altura.
- O número de bytes transferidos tem aumentado? A largura de banda que temos é suficiente?
- Os tempos de resposta estão dentro de intervalos que consideramos aceitáveis?
Com base na análise desta informação, formulamos hipóteses para as questões detectadas. Por exemplo, se os tempos de resposta aumentaram muito, mas as page views mantiveram-se nos mesmo níveis, será que foram introduzidas alterações ao site com impactos inesperados?
A fase seguinte passa pelo profiling dos servidores, tanto IIS como SQL ou outros. Para que o profiling nos dê informação fidedigna é necessário encontrar um equilíbrio entre o impacto que o profiling tem na performance e os períodos, por vezes congestionados, que necessitam de análise. Um ferramenta como a que usámos na fase anterior permite-nos determinar a actividade ao longo do dia e ajuda a determinar os períodos mais convenientes.
Ao nível do IIS, podem interessar contadores como o CPU, a memória (a nível global e por processo), os pedidos na fila de espera do IIS (Request Queued), os pedidos rejeitados (Requests Rejected), pedidos por segundo, entre outros. O guia Operating .NET-based Applications tem muita informação a este respeito.
Ao nível do SQL, os contadores também podem ser interessantes, mas neste caso o SQL Profiler é o vosso amigo (pelo menos, é o nosso). Nunca é demais louvar esta aplicação, pois é o maior apoio no diagnóstico de problemas de performance nas BDs. Muitas vezes, em casos como o nosso em que utilizamos intensivamente BDs, o problema está relacionado ou com índices que devem ser criados ou alterados ou com queries que não estão suficientemente optimizadas. O template que costumamos usar para um diagnóstico inicial (e muitas vezes suficiente) é o seguinte:
- Eventos
- TSQL - SQL:StmtCompleted.
- Stored Procedures - SP:StmtCompleted.
- Stored Procedures - SP:Completed.
- Agrupar por
- Colunas
- TextData
- Reads - A query é lenta por causa dos discos (por vezes é um sinal de table scans)?
- Writes - A query é lenta por causa dos discos?
- DatabaseID - Opcional. Só é útil se se analisar diversas BDs em simultâneo.
- CPU - A query é lenta por causa do CPU?
- Filtros
- DatabaseID - Para análise de uma só BD de cada vez.
- Duration - Filtrar todas as queries que levem menos de x milissegundos, para não existirem dados desnecessários no profile.
Este template permite-nos saber quais as queries mais lentas, que podem ter efeitos negativos transversais a todos os sites.
É claro que o tópico da performance é um mundo, mas qual é a área da informática que não se gaba de ser vastíssima? O ponto é que com este processo conseguimos detectar e resolver a esmagadora maioria dos problemas que não são detectados antes da aplicação passar a produção ou que só se manifestam com uma utilização real e não de laboratório.
Posted
15-11-2004 16:54
por
João Hugo Miranda