Olá, caros leitores!
Acredito que todos vocês, pelo menos alguma vez, já se irritaram com um software lento em algum estabelecimento. O que pode passar despercebido é que, além da irritação, a lentidão pode causar outros impactos, até mesmo na sociedade!
O papo de hoje, portanto, é sobre desempenho, um dos requisitos não-funcionais de uma aplicação. Acompanhe!
Introdução
Uma das motivações para escrever este artigo foi um acontecimento recente em uma instituição bancária. Eu retirei uma senha para abertura de conta e aguarei a chamada no telão. Nesse horário, haviam apenas dois atendentes disponíveis (a propósito, isso parece ser normal). Após algum tempo, notei que um dos atendentes parecia estar ocioso, como se estivesse esperando algo. Um homem que estava ao nosso lado, inconformado com a demora, questionou o atendente, que logo justificou-se: “O sistema está reiniciando.”.
Ponto final. Culpa do software. Este tempo de reinício atrasou o itinerário de todas as pessoas que estavam ali, esperando na fila. E o pior: de uma forma misteriosa, o sistema precisava ser reiniciado a cada atendimento.
Como consequência, cheguei vinte minutos atrasado no trabalho e perdi boa parte de uma reunião de planejamento de Sprint para definir estimativas e prioridades. Para que eu pudesse acompanhá-la, os participantes tiveram de voltar e fazer alguns repasses do que eu havia perdido. Por fim, a reunião excedeu 40 minutos do horário do expediente, prejudicando um dos desenvolvedores, que perdeu o primeiro horário da faculdade em função do atraso.
Tudo isso porque o sistema estava reiniciando…
Tempo é dinheiro
Se o exemplo acima não foi o suficiente, falaremos, então, de números. Afinal, tempo é dinheiro.
Suponha que uma empresa tenha 4 assessores contábeis e que o salário de cada um deles seja 4 mil reais. Associe os cálculos:
- 4.000,00 / 20 dias = 200,00 por dia;
- 200,00 / 8 horas = 25,00 por hora;
- 25,00 / 60 minutos = 0,42 por minuto.
Agora, considere que um conjunto de operações contábeis diárias no software da empresa (cálculos, importações, exportações e emissão de relatórios fiscais) demore cerca de 15 minutos, no total, para ser processado. Vamos voltar aos cálculos:
- 15 minutos * 0,42 = 6,30 por dia;
- 6,30 * 20 dias no mês = 126,00 por mês;
- 126,00 * 4 assessores = 504,00.
Mensalmente, há um custo improdutivo de 504,00 para a empresa devido aos 15 minutos diários de processamento, sem contar a insatisfação dos usuários. No ano, esse montante resulta em 6.048,00. É dinheiro pra dedéu, hein?
Prosseguindo com o exemplo, imagine que, após tomar conhecimento desse levantamento, o escritório contábil trocou os servidores e os equipamentos de rede na tentativa de reduzir o tempo e o stress dos assessores, porém, sem sucesso. Sabe por quê? A culpa é do software.
Parece radicalismo, mas o software assume, sim, a maior parte desse custo, muitas vezes por falta de conformidade com a questão do desempenho.
Só a título de conhecimento, se o tempo de 15 minutos fosse reduzido para 12, já haveria uma economia de aproximadamente 100,00 por mês. O valor pode parecer baixo, mas, em um ambiente real de produção, com vários funcionários (e provavelmente com um tempo de processamento bem maior do que 15 minutos), a diferença pode ser gritante.
Pare e reflita sobre supermercados, farmácias, restaurantes, hotéis, lojas e clínicas. Se o software em cada um desses estabelecimentos fosse um pouco mais rápido, mesmo em questão de segundos, já notaríamos uma diferença no nosso cotidiano, como, por exemplo, atendimentos e soluções mais eficientes, maior número de pessoas atendidas e menos irritação com a demora.
Foco no desempenho!
Bom, a boa notícia é que isso é possível!
O desempenho de uma aplicação pode ser melhorado de várias formas. A primeira ação, na qual considero extremamente importante, é a otimização de consultas SQL. Eu acredito que esse item é um dos grande vilões das lentidões em softwares. A simples remoção de uma cláusula JOIN em uma consulta já pode apresentar uma melhoria visível. Lembre-se do exemplo dos cálculos: qualquer segundo mais rápido é uma vantagem.
Uma boa dica é utilizar um monitor de instruções SQL para identificar leaks de consultas demoradas, duplicadas ou indevidamente executadas.
Em segundo lugar, existem várias técnicas para melhorar a performance do código da aplicação, principalmente relacionados a loops de repetição, I/O (leitura e escrita de arquivos), gerenciamento de recursos e manipulação de dados em memória. Não basta o software simplesmente fazer o que tem que fazer. Ele deve fazer bem feito.
Por fim, em terceiro lugar, apele para o bom senso e invista na simplicidade e usabilidade do software para agilizar o trabalho dos usuários e evitar insatisfações. Quanto mais prático, melhor. Nesse ponto, vale ressaltar o conceito de Engenharia de Valor. 🙂
Para finalizar, deixo três tópicos interessantes do blog que abordam um pouco dessas otimizações:
- CODEsign: Faça duas vezes!
- [Delphi] Dicas para agilizar o desempenho em uma DBGrid
- [Delphi] Orientações sobre a utilização de eventos de tela
- Práticas de otimização em Banco de Dados
Enquanto isso, a única saída é esperar na fila…
Abraços, pessoal!
Olá, André.
Já agonizei com isso, ou quase isso.
A demora de resposta de um software entre o tempo de pesquisa dos itens, a finalização de uma compra e a emissão de um “cupom de venda”, ou simples “pré-venda”, é quase 2 minutos, ou até mais em cada etapa.
Em uma loja, tipo um distribuidor de materiais no atacado, é ruim, mas para o consumidor final pode representar a desistência da compra e a procura de outro fornecedor mais rápido no atendimento.
Isso analisando só a parte principal (a Venda). A partir daí podemos imaginar as dificuldades na administração. Sem querer ser “Extremamente Radical”, 12 minutos para compilar um relatório (mesmo com grande volume de dados) é muito, mesmo que isso seja feito uma vez por mês.
Tomando como exemplo o volume de consultas que um comprador tem que fazer, para decidir quais itens e a quantidade destes, deve pedir para um fornecedor, que pode chegar a mais de 100 itens. Se cada consulta demorar 5 minutos (8hrs no total), fica inviável. Um até dois segundos para saber as vendas totais, a media mensal vendida e a posição atual do estoque, de um item, pode parecer pouco, mas não é.
Concordo e apoio a orientação dada neste artigo, devemos realmente nos preocupar com a performance do software que criamos.
Já li e fiz proveito dos tópicos citados. Parabéns por mais este artigo relevante.
Abraço!
Boa noite, Gerson!
Obrigado pela contribuição no artigo! Você tocou em um ponto importante: a desistência de consumidores. A demora no atendimento realmente causa esse tipo de consequência e ambos os lados saem perdendo. No depoimento que apresentei no artigo, sobre a instituição bancária, estávamos quase desistindo do atendimento, porém, sabíamos que, se voltássemos no dia seguinte, aconteceria a mesma coisa.
Eu costumo “bater na tecla” do desempenho porque muitos desenvolvedores subestimam esse aspecto. Em muitos dos casos, o desenvolvedor faz uma série de testes em um ambiente local de homologação (que normalmente é rápido), mas não se atenta que o ambiente de produção é outra realidade. A infraestrutura (terminais, servidores e rede) é diferente, assim como o número de usuários é maior. Portanto, todo ponto de melhoria de desempenho deve ser identificado no software. Uma diferença de 2 segundos em homologação pode equivaler a 10 segundos em produção.
Abraço!
Boa noite, André.
Para evitar esse problema de velocidade, eu uso uma máquina virtual (virtualbox) na criação e testes. Sempre fica melhor no cliente.
Sofro um pouco, na depuração, mas fico satisfeito com o resultado no cliente.
A situação que coloquei sobre o nº de consultas na decisão de uma compra, foi por observação do trabalho de alguns clientes. É bom sentar ao lado do usuário e observar como usam o software. Nós idealizamos uma coisa, criamos um ideal de uso, mas são eles que usam. Na maioria das vezes me surpreendendo com a agilidade e presteza de alguns, por isso dou atenção ao modo de trabalho dos usuários.
Acho que este tipo de análise não é possível em uma grande empresa de software, elas fazem?
Mais uma vez Obrigado, Pela atenção e dicas.
Abraço!
Olá, Gerson!
Sentar ao lado do usuário é uma excelente iniciativa para descobrir as dificuldades e dúvidas ao utilizar o software. Além disso, também é possível levantar melhorias para aumentar a produtividade dos usuários. Bem lembrado!
Em empresas de desenvolvimento que usam Desenvolvimento Ágil, essa função é desempenhada pelo Product Owner, um profissional que representa o cliente na equipe de desenvolvimento. Sendo assim, ao falar com o Product Owner, assumimos, tecnicamente, que estamos falando com o cliente! 🙂
Abraço!
Bom dia André, lendo seu artigo eu percebi que minha frente de caixa apresenta lentidão, eu uso uma tabela temporária para registrar os produtos antes de passar para tabela filho, quando passa 2 ou 3 produtos tudo ok mas se passar 10 produtos ele demora um pouco mais para executar a tarefa , o meu modelo de frente de caixa segue parecido com aquele artigo que você escreveu sobre tabelas temporárias, você tem alguma dica para que eu possa otimizar isso ? talvez retirando a tabela temporária ? Parabéns pelo Artigo , Obrigado e até mais .
Olá, André, tudo certo?
Boa pergunta! Na verdade, é um pouco difícil orientá-lo sem analisar o código. Tecnicamente essa lentidão não deveria ocorrer.
Verifique se, durante cada inserção, há alguma validação ou outro método que possa causar essa lentidão como, por exemplo, um loop de repetição em todos os produtos.
Abraço!
Boa tarde André, migrei uma aplicação de Delphi 7 para Delphi 10.2 e precisei trocar algumas Strings para AnsiString devido ao Unicode. Efetuando testes massivos, percebi que minha aplicação ficou muito lenta, acredito que a causa seja os Implicits type casts, pois existem lugares que uma variável AnsiString recebe uma String e necessitei fazer o type cast -> AnsiString := AnsiString(String). Há alguma outra maneira de fazer?
Olá, Jefferson, boa noite!
Acredito que esse tipo de typecasts não deveria prejudicar tanto a performance da aplicação. Suspeito que seja outro fator que está causando essa lentidão.
De qualquer forma, Jefferson, existe alguma restrição que o impede de alterar todas as variáveis String para AnsiString?
Fico no aguardo! Abraço!