Pontos-chave
|
“Essa página é lenta” é uma reclamação comum sobre web sites, especialmente desde que aplicações web começaram a substituir aplicações desktop. Enquanto a web tráz algumas características desejáveis como seu acesso global, ela também tráz sua parcela de desafios no que diz respeito a performance.
Porquê obter informações sobre performance
Seu usuário lhe apresenta a url de uma página “lenta”. Ótimo, mas e agora? De onde vem a lentidão? A página é realmente lenta para começo de conversa? É lenta para todos os usuários? Há várias questões a serem respondidas aqui para resolver o problema e ter certeza que a página não estará lenta novamente daqui uma semana.
Você pode encontrar material sobre otimização disponível online, muitas vezes sobre tópicos específicos como compilação JIT, garbage collection, otimização de consultas SQL, armadilhas no uso de uma ORM dentre outros. Embora seja tentador implementar uma otimização por parecer promissora, surge uma questão: como você sabe que a otimização irá realmente produzir bons resultados dado seu contexto?
É claro que uma peça do quebra-cabeças está faltando. Nós precisamos de uma maneira de encontrar problemas de performance, e de maneira contínua. Dessa maneira, nós sabemos o quê é lento e temos medidas concretas para apoiar-nos. Com esse conhecimento em mãos, é então possível determinar precisamente se as melhorias de performance são necessárias e explicá-las aos nossos clientes.
Identificar performance de maneira precisa é uma maneira muito mais eficiente de responder aos problemas de lentidão encontrados. O primeiro problema é que talvez não seja um problema de lentidão para começo de conversa. No caso de timeouts (onde o balanceador de carga pode servir a conexão depois de X segundos, por exemplo), é simplesmente impossível distinguir entre um deadlock e um tempo de resposta lento já que o resultado será o mesmo, um timeout. É necessário obter dados para encontrar o real problema.
Para ilustrar a importância de identificar problemas de performance de forma precisa, aqui vão alguns possíveis pontos de lentidão em uma aplicação web:
- JavaScript lento;
- Bloqueio na renderização de algum recurso;
- Proxy no lado do usuário;
- Problemas com DNS;
- Problemas com provedor de internet;
- Problemas com switch ou roteador;
- Balanceador de carga;
- Código da aplicação (incluindo bibliotecas de terceiros);
- Servidor HTTP (algo do ASP.NET ou IIS, por exemplo);
- Serviços de terceiros como processadores de pagamento, provedores de mapas, etc;
- Outros sistemas como SQL Server, Redis, Elasticsearch, Rabbit MQ, etc.
E a lista continua, dependendo da complexidade e escalabilidade que você tem que lidar. Como diagnosticar um problema de performance quando tantos componentes estão em jogo? Uma palavra: dados. Você quer dados relevantes e significativos para tudo. Dados podem provar a culpa ou a inocência de um sistema envolvido em uma requisição lenta.
Com dados em mãos, você pode começar pelo topo e ir tirando componentes fora da lista conforme prosseguir, similar a uma busca em uma árvore ordenada. Você ficará mais próximo dos detalhes e do real problema a medida que for caminhando na árvore:
- Client side, server side ou algo no meio?
- JavaScript lento, renderização, carregamento de recursos bloqueando?
- Balanceador de carga, servidor web, algum sub-sistema ou sistema terceiro?
Conforme navegamos na árvore, o problema vai ficando mais e mais preciso. Sendo assim, a informação necessária para encontrar o problema deve possuir esse mesmo nível de precisão. Nesse ponto, ferramentas como profilers de performance ou planos de execução de consultas SQL se fazem necessários.
Vale citar a Lei de Amdahl:
Regardless the magnitude of an improvement, the theoretical speedup of a task is always limited by the part of the task that cannot benefit from the improvement.
Por exemplo, suponha que temos uma requisição web tomando 100ms do processamento do servidor e 5 segundos para uma query SQL. Mesmo que você consiga abaixar o processamento do servidor para apenas 1 ms, a melhora é marginal em termos de tempo de resposta, que vai de 5.1 para 5 segundos. Os 5 segundos de processamento SQL são onde o potencial de ganho é maior.
Problemas de infraestrutura
Uma abordagem de fora para dentro, que identifica um problema de maneira cada vez mais precisa, funciona bem no caso de um problema localizado em apenas uma página. Mas e aqueles que ocorrem em várias páginas? E se, por exemplo, várias páginas sofrem de forma intermitente de um tempo de resposta lento devido a um sub-sistema não estar conseguindo servir seus pedidos ou devido à um antigo switch de rede no qual cada reinício corre o risco de ser seu último?
Aqui é onde a abordagem de monitoria focada apenas na aplicação mostra suas limitações. Nesse nível, outras métricas são necessárias para avaliar a saúde de cada componente do sistema, tanto no nível de software quanto de hardware.
No nível de hardware, as primeiras máquinas que vêm em mente são os servidores web e de banco de dados. Contudo, estas são apenas a ponta do iceberg. Todos os componentes de hardware devem ser identificados e monitorados: servidores, switch de rede, roteadores, balanceadores de carga, firewall, etc.
Tudo isso pode parecer óbvio para um administrador de sistemas, já que o monitoramento de hardware é uma prática comum. Há, porém, que utilizá-los com cautela: todas as métricas de hardware são em sua maioria inúteis de um ponto de vista de performance se elas estão separadas das métricas da aplicação. Em outras palavras, métricas são mais úteis quando colocadas em contexto.
Por exemplo, uma média de 50% de uso de CPU em um servidor de banco de dados pode ser completamente normal em alguns casos e uma bomba relógio em outros. Em horários de pico, 50% de uso de CPU indica que ainda há espaço para acomodar um tráfego ainda maior. Se o mesmo 50% ocorre com frequência durante períodos ociosos, isso sugere que é improvável que a aplicação sobreviverá à um súbito aumento de requisições.
Em resumo, métricas de todo um sistema como CPU, memória e uso de disco devem estar relacionadas à métricas de aplicação para assegurar seu bom funcionamento. Estar apto a visualizar métricas de aplicação como o throughput de requisições e métricas de sistema como uso de CPU, oferece uma visualização muito mais completa do funcionamento de um sistema.
Ferramentas de monitoramento de performance (APM)
Ferramentas APM provêem as operações básicas de coleta, armazenamento e visualização de dados. Geralmente um agente fica a cargo de coletar os dados e enviá-los ao banco de dados. Utilizando a interface web, os dados podem ser visualizados através de painéis de controle centrados nas requisições web.
Ferramentas de APM são úteis para:
- Visualizar a performance de uma aplicação web como um todo
- Visualizar a performance de requisições específicas
- Enviar alertas automáticos quando a aplicação web estiver com baixa performance ou estiver com muitos erros
- Verificar como a aplicação responde em período de grande utilização
Segue abaixo uma pequena lista de ferramentas APM com suporte out-of-the-box para ASP.NET e IIS:
Ferramentas de monitoramento de infraestrutura
Para dar uma ideia completa, ferramentas de monitoramento de infraestrutura coletam métricas em nível de máquina. Métricas são coletadas tanto em nível de hardware quanto de software.
Profilers leves
Profilers leves dão métricas de alto nível em uma requisição web em particular. Elas provêm feedback imediato ao desenvolvedor a medida que ele navega pelas páginas. Eles podem ser utilizados em todos os tipos de ambiente (desenvolvimento, testes, produção, etc) fazendo com que eles sejam adequados para certificar de maneira rápida a performance uma página em particular.
A diferença fundamental em profilers leves sobre os profilers mais completos é que eles não estão ligados ao processo em execução. Isso significa que você pode utilizá-los sem maiores preocupações com seu overhead.
No contexto do desenvolvimento, profilers leves provêm feedback imediato no código que você está escrevendo. Isso é particularmente útil para achar problemas como N + 1 ou um tempo de resposta lento, pois você sempre terá o tempo de resposta exibido no canto da página.
Contadores de performance para tapar os buracos
Contadores de performance no Windows provêm métricas em diferentes aspectos em nível de hardware e software. Ferramentas de monitoramento geralmente reportam alguns contadores de performance como uso de CPU e memória. No entanto, alguns contadores úteis como tempo de garbage collector com frequência estão ausentes. A maneira mais prática de começar é utilizar uma lista básica e adicionar contadores relevantes conforme necessário.
É possível coletar e visualizar contadores de performance em tempo real utilizando perfmon. Integração com APMs também é possível na maioria dos casos, utilizando métricas personalizadas ou plugins.
Ferramentas SQL
A camada de persistência é frequentemente um gargalo devido a sua onipresença na maioria das aplicações. Ferramentas especializadas de monitoramento SQL provêm métricas em utilização de recursos assim como métricas específicas como tempo de espera ou compilações por segundo, para dar alguns exemplos.
Você pode encontrar vários tipos de problemas assim como vários tipos de melhorias de performance com os dados obtidos:
- Throughput excessivo em algumas consultasExcessive throughput on one or several queries
- Uso excessivo de CPU dando ideia de problemas de consulta ou índices faltando
- Consultas de alto throughput que podem ser colocadas em cache
Ferramentas de monitoramento SQL:
Outros sistemas de persistência
Todos os sub-sistemas precisam ser monitorados até certo ponto. Uma coleta e visualização de dados simples podem ser suficientes para um sistema de baixo throughput ou sistemas de criticidade baixa. Em outros casos, eles demandam monitoramento mais avançado e especializado.
Profilers de código
Quando uma página em particular ou um trecho de código são identificados como lentos, um profiler de código provê uma visão mais detalhada para identificar um problema de performance. Eles também dão uma visão precisa de chamadas externas como consultas à banco de dados e requisições web.
Profilers:
Profilers de memória
Monitorar memória e métricas de garbage collector são úteis para detectar problemas em potencial. Enquanto eles mostram a presença de um problema, eles normalmente não falam onde está. Um profiler de memória é útil quando há necessidade de adentrar em problemas de memória ou garbage collector.
Profilers:
Profiler client side
Também podem aparecer problemas de performance do front-end. Isso se tornou especialmente verdade com o surgimento de aplicações SPA (single page application), onde o JavaScript reina. Todos os principais browsers trazem ferramentas de profiler de código e memória embutido.
Ferramentas mostrando a sequência de eventos e requisições são úteis ao determinar com prontidão se um problema vem do front-end ou back-end.
Ferramentas
Analisadores de página
Ferramentas client side de alto nível são úteis no começo da análise do problema de performance. Essas ferramentas podem dar uma vis∫ao alto nível de onde os problemas com tempo de respostas vêm, além de dar algumas recomendações. O PageSpeed Insights do Google é um exemplo gratuito de ferramenta.
A simples quantidade de fatores e ferramentas envolvidas em performance de um sistema podem assustar. Entretanto tudo pode ser resumido em uma palavra: dados. Ter uma visão clara e precisa de um sistema em um dado momento faz com que seja possível raciocinar sobre sua performance. Isso também fornece um aprendizado de momento, onde os gráficos e as métricas de performance podem te guiar até o que está impactando em seu sistema.
Sobre o Autor
Pierre-Luc Maheué um desenvolvedor de software que trabalho com VoIP, hospedagem na nuvem e-commerce nos últimos cinco anos. Ele atualmente trabalha para Amilia, uma plataforma SaaS que gerencia cadastros online. Seus interesses atuais são monitoramento, performance/escalabilidade e F#. Em seu tempo livre, ele gosta de limpar sua mente praticando escalada indoor, Animal Flow e Kendo.