Quando o muito atrapalha

Durante as duas últimas semanas venho trabalhando intensamente em um sistema, onde um dos principais problemas é a lentidão de processamento de determinadas telas. O sistema é web (ASP.NET), usa JQuery para interfaces e o banco de dados é SQL Server.

Fato: Não tive a oportunidade de desenvolver aplicativos nos primórdios da informática, onde a definição de um tipo de dado deu ma declaração variável ou tipo de coluna em uma tabela de dados precisavam ser analisados com cuidado, com o objetivo de preservar os escassos recursos de memória e disco rígido.

Mas, tive a felicidade de trabalhar com o Júlio, um cara com uma vasta experiência nesse ambiente onde otimizar era uma necessidade, e com isso veio a oportunidade de aprender detalhes simples, outros nem tanto, na melhoria de sistemas. Este é o principal motivo com o qual, consegui implementar mudanças que significaram em um ganho de até doze vezes na performance desse sistema.

Em primeiro lugar, vamos deixar bem claro: Quem trata os dados, é o servidor de banco de dados. Parece óbvio, mas não é. O aplicativo recebia todos os dados em objetos LINQ, e lá eram tratados com relação a filtros e paginação de registros no grid. Ganhamos bastante quando comecei a escrever stored procedures que, além de filtrar esses dados no SQL Server, onde existem os índices e chaves primárias, passei a retornar para o servidor web apenas os dados que realmente interessam ao grid, ou seja, vinte registros por vez.

Em segundo lugar: Evite loops enormes em javascript. Conseguimos melhorar muito, também com stored procedures, algumas situações onde um campo com suggestion, realizava um loop enorme em um objeto JSON em memória. Simplesmente passamos a exigir um mínimo de caracteres a serem digitados para uma pesquisa remota.

Em terceiro lugar: Comentários Javascript ou HTML não devem existir na produção. Alguns arquivos tinham 5k de coisas inúteis, comentários de códigos de teste que, por algum motivo, ainda estavam lá, esquecidos. O controle de versão existe justamente para o caso de alguma coisa sair errado e você tem a oportunidade de voltar na versão anterior.

Em quarto lugar: Quer testar algum plugin JQuery? Faça em um ambiente local, veja os demos de quem publicou. Eliminei alguns arquivos CSS e JS que estavam referenciados sem a menor necessidade.

E a regra geral: Procurar estudar os detalhes da aplicação antes de modelar alguns tipos de dados no banco de dados. Quase sempre, é possível ganhar em desempenho geral aplicando os tipos de dados corretos para uma coluna. Nesse sistema, haviam vários campos criados com VARCHAR(100) sem a menor necessidade, coisa que um CHAR(10) resolveria.

A lição fica em sempre procurar melhorar o desempenho. Mesmo que algum detalhe possa parecer mero preciosismo, em algum tempo o aumento na quantidade dos dados e o conseqüente crescimento no número simultâneo de acessos, justifica qualquer minuto, ou hora, que você investir em tarefas de análise como esta. Duvide sempre da performance do seu sistema em condições de desenvolvimento, executando a aplicação em seu computador, localmente.

Agora, o pior para o desenvolvedor: Acredite no usuário. Sim, ele mesmo! O usuário do seu sistema sempre tem algo para dizer, mesmo que ele não saiba exatamente como explicar. Nesse projeto, o principal cliente utiliza o Internet Explorer 7, é ruim, sim… é péssimo. Mas, de uma maneira ou de outra, foi necessário melhorar algumas situações para esse navegador. Depois que isso foi feito, o cliente percebeu a diferença, e agora como em um passe de mágina, ele próprio quer atualizar sua versão: Se já melhorou com o antigo, imagine com o novo! Pronto, cliente percebeu que você se empenhou e agora ele fará o mesmo.

Anúncios

Um comentário em “Quando o muito atrapalha

  1. Muito bom, menos é mais, já dizia a teoria do minimalismo.
    Algumas outras dicas legais:
    Javascripts podem ser reduzidos com alguns scripts de minificação, outra boa dica é juntar todos os scripts em um arquivo apenas. Isso diminui as requisições do servidor e melhora o cache, poupando alguns kbs.
    Imagens podem ser unidas em um arquivo só, chamado de SPRITE, essa técnica reduz e muito a quantidade de requisições e se bem otimizado também reduz o tamanho total de load, poupando mais alguns kbs.
    Outra dica interessante para sites com grandes carregamentos e muito acesso simultâneo é ter um cache na ponta, como o SQUID para PHP. Em sites com centenas de acessos simultâneos um cache de 10 minutos pode fazer uma grande diferença entre seu site estar no ar ou não.
    Se não me engano SQLServer tem um esquema de fazer cache de consultas repetidas, evitando assim consultas desnecessárias ao banco.
    =)

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s