P of EAA - Introdução - Thinking About Performance #2

No último post, falamos um pouco sobre o livro Patterns of Enterprise Application Architecture de Martin Fowler, o que são Aplicações Corporativas e quais os tipos de Aplicações corporativas.

Neste post, continuaremos falando sobre outra parte introdutória do livro, onde é intitulado como "Thinking About Performance". O foco deste livro não é performance, entretanto, sempre que tomamos uma decisão arquitetural, ou até mesmo de design, elas estão de certa forma relacionada a performance. Com isso, algumas decisões arquiteturais podem afetar a performance da aplicação, dificultando a correção, mesmo quando a correção é fácil, geralmente as pessoas envolvidas no projeto, não se preocupam com a performance, e sim, realizar a correção rapidamente. Lembre-se: Sua aplicação sempre deve estar preparada para mudanças.

Whenever you do a performance optimization, however, you must measure both before and after, otherwise, you may just be making your code harder to read. (Patterns of Enterprise Application Architecture, Martin Fowler)

Essa citação foi uma das dicas mais importantes que extrai deste trecho do livro. É sempre importante mensurarmos nossa performance, entre antes e após a mudança, caso contrário, você estará apenas adicionando complexidade a sua aplicação.

Termos e medidas

Um problema quando falamos sobre performance, é que muitos termos são utilizados de forma "errada" e muitas vezes levando a tomada de decisões em caminhos diferentes. Um exemplo disso é o termo "escalabilidade" que muitas vezes, é utilizada referenciando diferentes coisas.

Vamos falar sobre os termos utilizados e seus significados, baseados no livro:

• Response time: é a quantidade de tempo que se leva para processar uma requisição. Seja no front-end, a partir de um clique em um botão, ou uma chamada em uma API.

• Responsiveness: Essa medida é um pouco complexa, mas, entenda que é o quão rápido o sistema reconhece uma requisição e retorna uma resposta ao usuário para o usuário. Este é um ponto MUITO importante. Muitas vezes o usuário se sente frustrado, pois foi realizar determinada ação em um sistema e teve que ficar aguardando a resposta do processamento, sem nenhum tipo de acompanhamento de como estava a solicitação. Isso significa que o Responsiveness está baixo. Com isso, caso o sistema receba uma requisição e indique que recebeu, antes de processá-la, seu responsiveness é melhor. Obs: Seu Responsiveness pode ser melhor ainda, caso você consiga dar um acompanhamento ao usuário de como está o processamento da requisição. Como por exemplo, utilizar uma barra de carregamento no front-end.

• Latency (Latência): é o tempo minimo de resposta necessário para obter qualquer tipo de resposta. Mesmo executando um serviço não existente.

• Throughput: Mede o quanto de coisa seu sistema consegue realizar em determinado tempo. Se você está processando um arquivo, por exemplo, você pode medir seu throughput mensurando bytes por segundo. Geralmente em aplicações corporativas, o throughput é mensurado por transactions por segundo. Segue anotação importante relacionada ao throughput.

  In this terminology performance is either throughput or response time— whichever matters more to you. It can sometimes be difficult to talk about performance when a technique improves throughput but decreases response time, so it’s best to use the more precise term. From a user’s perspective responsiveness may be more important than response time, so improving responsiveness at a cost of response time or throughput will increase performance. (Patterns of Enterprise Application Architecture, Martin Fowler)

• Load (Carga): Mensura de forma declarativa qual a quantidade de stress um sistema suporta sob determinada situação, por exemplo, quantos usuários estão conectados simultaneamente. Geralmente a carga, está relacionada a algum contexto, exemplificando, você poderia dizer que o response time será de 0.5s para 10 usuários e 2s para 20 usuários.

• Load sensitivity: É uma expressão que indica como o response time varia de acordo com a carga. Supondo que o Sistema A tenha um response time de 0.5s para 10 à 20 usuários, e o Sistema B tem um response time de 0.2s para 10 usuários, porém, 2s para 20 usuários. Podemos dizer que neste caso, o sistema A tem um baixo load sensivity para o Sistema B. Ou também é utilizado o termo "degrades", podendo-se dizer que o sistema A degrada ao sistema B.

• Efficiency (Eficiência): Se trata do desempenho dividido por recursos. Por exemplo, um sisteea pode receber 30 tps (transactions per seconds) em 2 CPU's é mais eficiente do que um sistema que recebe 40 tps em 4 CPU's identicos.
• Capacity (capacidade): Indica o throughput ou carga máxima que um sistema suporta. Pode ser absolutamente um ponto máximo, ou pode ser um ponto onde sua performance atinja um threshold aceitável.
• Scalability: é uma medida que mensura como adicionar recursos ao sistema (geralmente hardware) afeta o seu desempenho. Sendo assim, um sistema escalável é um sistema que ao adicionar um novo recurso, você obterá um desempenho proporcional.
• Vertical Scalability ou Scaling up (Escalar verticalmente): Significa adicionar forças a um recurso. Como por exemplo, adicionar mais memória a um server.
• Horizontal Scalability ou scaling out: Significa adicionar mais recursos, como por exemplo, adicionar mais servidores.

No próximo post, iremos enfim, começaremos a falar sobre os Patterns catalogados neste livro, a estrutura destes patterns e suas limitações. Espero que este post agregue de alguma forma para vocês <3