Falando de Desempenho
Esses dias lendo o livro do Fowler (PoEAA), ele comenta um pouco sobre desempenho e como muitos dos termos de desempenho são usados de forma inconsistente. Para melhorar a comunicação de equipes de desenvolvimento de software resolvi publicar alguns termos e seus respectivos significados.
- Tempo de Resposta
É a quantidade de tempo que o sistema leva para processar uma solicitação externa. Pode ser uma ação na interface com o usuário, como o pressionamento de um botão, ou uma chamada de API do servidor.
- Agilidade de Resposta
A agilidade de resposta diz respeito ao quão rapidamente o sistema reconhece uma solicitação (em oposição ao tempo que leva para processá-la). Isso é importante em muitos sistemas porque os usuários podem ficar frustrados se um sistema demorar para responder a uma solicitação, ainda que seu tempo de resposta seja bom. Se o seu sistema esperar durante toda uma solicitação, então sua agilidade de resposta e o seu tempo de resposta são os mesmos. Entretanto se você indicar que recebeu a solicitação antes de completá-la, então sua agilidade de resposta é melhor.
- Latência
É o tempo mínimo requerido para obter qualquer forma de resposta, mesmo se não houver nenhum trabalho a fazer. Se eu pedir a um programa para não fazer nada, então devo receber uma resposta quase instantânea se o programa rodar na minha máquina local. Entretanto, se o programa rodar em um computador remoto, pode demorar alguns segundos devido ao tempo gasto para que a solicitação e a resposta cheguem a seu destino através da conexão. Como desenvolvedor de aplicações, geralmente, nada posso fazer para melhorar a latência. A latência é o motivo pelo qual devemos minimizar chamadas remotas.
- Throughput
É a quantidade de coisas que você pode fazer em uma dada quantidade de tempo. Se você estiver contabilizando o tempo gasto na cópia de um arquivo, o throughput poderia ser medido em bytes por segundo. Para aplicações corporativas, ume medida típica é o número de transações por segundo (tps), mas o problema é que isso depende da complexidade da sua transação.
Nesta terminologia, desempenho pode significar tanto throughput quanto tempo de resposta – o que for mais importante para você. Às vezes, pode ser difícil falar sobre desempenho quando uma técnica melhora o throughput, mas piora o tempo de resposta. Assim é melhor usar o termo mais preciso. Da perspectiva de um usuário a agilidade de resposta em detrimento do tempo de resposta ou do throughput aumentará o desempenho.
- Carga
A carga é uma medida da pressão a que o sistema está submetido, que poderia ser medida pelo número de usuários a ele conectados em um determinado instante de tempo. A carga é geralmente um contexto para alguma outra medida, como um tempo de resposta. Assim, você pode dizer que o tempo de resposta para alguma solicitação é de 0,5 segundo com 10 usuários e de 2 segundos com 20 usuários.
- Sensibilidade de carga
É uma medida de como o tempo de resposta varia com a carga. Digamos que o sistema A tenha um tempo de resposta de 0,5 segundo para um número de usuários entre 10 e 20, e o sistema B tenha um tempo de resposta de 0,2 segundo para 10 usuários que aumenta para 2 segundos com 20 usuários. Neste caso o sistema A tem uma sensibilidade de carga menor do que o sistema B.
- Eficiência
A eficiência é o desempenho dividido pelos recursos. Um sistema que obtenha 30 tps com duas CPUs é mais eficiente que uma que obtenha 40 tps com quatro CPUs idênticas.
- Capacidade
A capacidade de um sistema é uma indicação do máximo throughput efetivo ou máxima carga efetiva. Este poderia ser um máximo absoluto ou um ponto a partir do qual o desempenho caia abaixo de um limite aceitável.
- Escalabilidade
A escalabilidade é ume medida de como o acréscimo de recursos (normalmente hardware) afeta o desempenho. Um sistema escalável é aquele que lhe permite adicionar hardware e obter uma melhora de desempenho proporcional, como dobrar o número de servidores disponíveis para dobrar o throughput. A escalabilidade vertical, ou escalar para cima, significa adicionar mais poder a um único servidor (por exemplo, acrescentar memória). A escalabilidade horizontal, ou escalar para fora, significa adicionar mais servidores.
O problema aqui é que as decisões de projeto não afetam todos esses fatores de desempenho de forma igual. Digamos que temos dois sistemas de software rodando em um servidor: a capacidade do Peixe-Espada é de 20 tps, enquanto a do Camelo é de 40 tps. Qual dos dois tem melhor desempenho? Qual é mais escalável? Não podemos responder a questão de escalabilidade com estes dados, e a única coisa que podemos dizer é que o Camelo é mais eficiente em um único servidor. Se adicionarmos outro servidor, percebemos que o Peixe-Espada agora trata 35 tps, e o camelo 50 tps. A capacidade do Camelo ainda é melhor, mas parece que o Peixe-Espada pode ter melhor escalabilidade. Se continuarmos adicionando servidores, descobriremos que o Peixe-Espada obtém 15 tps por servidor adicional e que o Camelo obtém 10. Com esses dados, podemos dizer que o Peixe-Espada tem uma melhor escalabilidade horizontal, ainda que o Camelo seja mais eficiente com menos de cinco servidores.
Os projetistas muitas vezes fazem coisas complicadas que aumentam a capacidade de uma plataforma específica de hardware quando, em verdade, poderia ser mais barato comprar mais hardwares. Se o Camelo tem um custo maior do que o Peixe-Espada, e esse custo maior é equivalente a um par de servidores, então o Peixe-Espada acaba sendo mais barato, mesmo se você precisar de apenas 40 tps. Está na moda reclamar por ter que depender de hardware melhor para fazer o nosso software rodar apropriadamente. No entanto, adquirir hardware mais novo é com freqüência mais barato do que fazer o software rodar em sistemas menos poderosos. De forma semelhante, adicionar mais servidores é freqüentemente mais barato do que adicionar mais programadores – desde que o sistema seja escalável.
