Por que meu site está lento? 5 erros que você pode estar cometendo!

0002

Imagine o seguinte cenário: Você contrata uma infraestrutura de altíssima capacidade, capaz de suportar com folga sua aplicação. Essa infraestrutura é cara, mas o importante é atender o cliente com qualidade e, claro, com isso aumentar a chance de converter a visita ao site em venda.

Entretanto, ao subir a aplicação, você percebe que seu cliente não está satisfeito. Os tempos para realizar as operações estão altos. Por exemplo, sete segundos para realizar uma simples busca? E o problema não é infraestrutura, as máquinas têm capacidade ociosa. Então, o que pode ser?

Trabalhando com testes de desempenho na Base2 Tecnologia há mais de 5 anos, observei diversos problemas em vários sistemas diferentes, como por exemplo aplicações bancárias, hospitalares e sites de comércio eletrônico. Desses problemas, alguns se sobressaem como os mais populares. Neste artigo, serão apresentados os 5 erros mais comuns que as empresas cometem e que reduzem significativamente o desempenho das aplicações.

1. Balanceamento de Carga

Muitas vezes, para melhorar o desempenho, são empregadas mais de uma máquina realizando a mesma atividade. Por exemplo, diversas máquinas podem ser responsáveis por realizar a busca por produtos. As diversas buscas são distribuídas entre as diversas máquinas, de sorte que cada máquina fique responsável por responder um subconjunto dessas pesquisas. Dessa maneira, um volume grande de buscas pode ser dividido entre diversas máquinas.

A ideia é ótima, já que fornece maior robustez, ao permitir que o sistema continue a operar caso um ou mais servidores falhe(m). E ainda permite maior vazão, ou seja, um volume maior de clientes pode ser atendido, já que esses atendimentos podem ser distribuídos entre os servidores disponíveis.

Até aí tudo ótimo. Porém, um erro comum é justamente configurar como essas solicitações serão distribuídas entre os servidores. Há diversas estratégias que podem ser aplicadas, e elas, por si só, merecem um artigo. Mas uma regra de ouro é verificar se todos os servidores apresentam, na média, o mesmo uso de recursos (consumo de processador, memória, IO etc). Isso sinaliza que a estratégia escolhida é adequada. Caso contrário, você não está aproveitando a infraestrutura como poderia, e pode estar deixando clientes insatisfeitos tendo capacidade ociosa.

2. Planejamento

Normalmente, quando se fala em carga, na maior parte dos negócios, ela tem um comportamento previsível. Em um determinado período, há um volume mais alto de acessos. Por exemplo, o volume de acessos a um comércio eletrônico cai durante a madrugada. Já as universidades têm um período fixo de matrícula.

Conhecer os padrões de comportamento dos usuários é fundamental, já que permite aproveitar ociosidade combinando sistemas que tenham cargas complementares. Ou seja, compartilhar infraestrutura entre sistemas que tenham uso em momentos diferentes.

No entanto, um erro comum, é ignorar esses padrões e agendar operações de rotina, tais como backups ou atualizações em momentos de alta carga no ambiente. Então, não pensar em uma janela específica, por exemplo para backup do banco de dados, em um momento de baixa demanda, pode ser um erro grave.

3. Vazamento de Memória

Me lembro com um pouco de nostalgia dos meus tempos de faculdade programando em C, onde o programador é o responsável por alocar e desalocar memória explicitamente!

As linguagens de mais alto nível hoje apresentam um mecanismo de coleta de lixo, que basicamente permite que você aloque variáveis e objetos sem se preocupar em desalocá-los explicitamente no futuro. O coletor de lixo verifica que uma variável não está sendo usada e a retira da memória, devolvendo essa memória para o Sistema Operacional. Simples assim!(?).

A grande pegadinha nisso é que os desenvolvedores ficam menos atentos à liberação de memória. Então, acabam mantendo na memória variáveis não utilizadas, basicamente esquecendo-se de eliminar todas as referências a essa variável. E essa referência pode ser sutil, não remover o objeto de uma lista, por exemplo. E se houver algum outro elemento referenciando a esse objeto, o coletor de lixo nunca saberá que pode eliminá-lo com segurança.

Assim, esse erro pode ser complicado de ser diagnosticado. E ainda mais difícil de ser corrigido, especialmente se considerarmos a complexidade dos códigos e o uso de frameworks de terceiros.

4. Banco de dados

O banco de dados pode ser uma grande fonte de problemas que gerem queda de desempenho. Consultas e operações no banco (queries) podem ter sido escritas de maneira complexa e ineficiente. Ainda, configurações no banco de dados, como a criação de índices em colunas importantes, podem reduzir o tempo gasto no banco de dados.

5. Pool de conexões

Há diversos pools de conexão com os quais as aplicações precisam lidar. Esses pools, quando tem um volume máximo de conexões, atuam basicamente como um conjunto de permissões para acesso simultâneo a um recurso. Então, se um determinado pool possui limite de 30 conexões no máximo, isso quer dizer que ele permite 30 acessos simultâneos a um recurso. Há outras características e vantagens do uso de pools de conexão, mas do ponto de vista deste artigo, vamos enfatizar somente a restrição de simultaneidade que podem impor.

Os pools mais comuns são entre o cliente e o servidor e entre o servidor de aplicação e o banco de dados. Alguns servidores modelam o ciclo de vida de uma operação passando por diversos outros pools. O limite no pool entre o cliente e o servidor de aplicação diz quantos clientes simultâneos o servidor consegue atender. O limite de conexões no pool do banco de dados diz quantas consultas e operações simultâneas podem ser tratadas pelo banco de dados.

Quando os limites nos pools não estão calibrados adequadamente, as solicitações dos usuários em geral são enfileiradas e demoram para serem atendidas, com isso vemos uma queda no desempenho, mesmo que haja capacidade ociosa no ambiente.

Esses são os erros mais comuns que impactam profundamente o desempenho das aplicações. Então, está cometendo algum deles? Existe algum erro que você já vivenciou e não está listado aqui? Compartilhe conosco!

About César Fernandes

Graduado e mestre em ciência da computação pela Universidade Federal de Minas Gerais (UFMG). Concluiu o MBA de Gestão Estratégica da Tecnologia da Informação na Fundação Getúlio Vargas (FGV). Possui experiência técnica e acadêmica em robótica, análise e modelagem de desempenho e simulações econômicas baseadas em múltiplos agentes. É Coordenador de Projetos na Base2.