Calcular TPS em uma arquitetura distribuída

Calcular transações por segundos para processamento de transações em uma arquitetura distribuída

Vale apontar que eu poderia escrever esse artigo usando "1 segundo" como referencia para o calculo e minha vida seria mais simples. Mas no dia a dia, não é o que acontece. São poucas empresas possuem software que respondem todas as requests em menos de 1 segundo. Então, vamos ao caos.



Cenário: identificar TPS adequado para aplicação que possui tempo de resposta médio de 3 segundos.

Por onde começar?

Vamos executar um teste de carga/stress para identificar qual limite que venha a gerar  algum impacto em qualquer ponto da aplicação (seja no servidor de aplicação ou no banco de dados, por exemplo)

Exemplo de execuções:

O cenário abaixo é totalmente hipotético. Será apenas para exemplificar algumas execuções de testes que no nosso cenário hipotético resultaram em um número de execuções que minha aplicação consegue processar dentro dos 3 segundos (média de tempo de resposta da nossa aplicação).

10 requisições a cada 3 segundos.
- Nenhuma degradação observada
15 requisições a cada 3 segundos.
- Nenhuma degradação observada

20 requisições a cada 3 segundos.
- Banco de dados sofreu degradação observada

17 requisições a cada 3 segundos.
- Nenhuma degradação observada

Então, podemos concluir que 17 é nosso limite por intervalo de 3 segundos para essa aplicação.

LIMITE_TESTE_CARGA = 17

Analisar o histórico:

Certamente observar comportamento de usuário requer métricas e essa é a primeira coisa que você deve fazer quando coloca uma aplicação em produção. No meu caso, vou pressupor que tenho os logs das minhas requests no servidor de aplicação, então vou pegar o histórico de 7 dias, identificando os horários de maior pico e tirar a média com base nos picos. 
É importante informar também que esse intervalo depende muito do negócio. Se for uma varejo por exemplo, a sazonalidade e a situação econômica do pais, pode mudar drasticamente os números. Mas para exemplificar, vou trabalhar considerando um cenário onde uma aplicação possui um certo padrão de consumo com variações suficientes em um período de uma semana (do contrário eu não terminaria esse artigo hoje):

- No dia 1, observamos que as 15:00 tivemos o maior pico do dia, com 12 acessos em um intervalo de 3 segundos.

- No dia 2, observamos que as 12:00 tivemos o maior pico do dia, com 11 acessos 
em um intervalo de 3 segundos.

- No dia 3, observamos que as 09:00 tivemos o maior pico do dia, com 9 acessos 
em um intervalo de 3 segundos.

- No dia 4, observamos que as 18:00 tivemos o maior pico do dia, com 7 acessos 
em um intervalo de 3 segundos.

- No dia 5, observamos que as 15:30 tivemos o maior pico do dia, com 13 acessos 
em um intervalo de 3 segundos.

- No dia 6, observamos que as 08:00 tivemos o maior pico do dia, com 10 acessos 
em um intervalo de 3 segundos.

- No dia 7, observamos que as 09:00 tivemos o maior pico do dia, com 9 acessos 
em um intervalo de 3 segundos.

Então, podemos concluir que (12+11+9+7+13+10+9) / 7 = 10

MEDIA_PICO_7_DIAS = 10

Variação entre os picos e o teste de carga:

O limite de TPS é basicamente uma subtração da média dos picos sobre o resultado do teste de carga:

Então, 17 - 10 = 7

LIMITE_TPS = 7

Certo, e?

Isso nos indica que nossa aplicação poderia (baseado na média), trabalhar com um limite de 7 transações em um intervalo de 3 segundos para processar uma fila de requisições. Porém, imagine que estamos falando do dia 5, que tivemos um pico de 13. Imaginando que também vamos atingir pico no processamento da fila nessa nova aplicação, então teríamos problemas pois 13 + 7 = 20. Vinte (20), no nosso teste de carga foi um número que degradou nosso banco. Então o adequado é trabalhar abaixo da margem. Mas não temos esse número pois é uma nova aplicação, ou seja, precisamos usar a experiência que temos (histórico) para gerar uma variável que usaremos como margem de segurança.

Variação entre os picos e o teste de carga:



Podemos usar os mesmos 7 dias, ou até olhar para um tempo maior (buscando o pico nos últimos 30 dias, por exemplo - tudo vai depender do comportamento do seu usuário). Imaginando que optamos pelos 7 dias, o maior número foi 13. Então definimos a variável:

MAIOR_PICO_7_DIAS = 13

e aplicamos o calculo de variação percentual abaixo:

VARIACAO = ((LIMITE_TESTE_CARGA - MAIOR_PICO_7_DIAS) / MAIOR_PICO_7_DIAS) * 100

ou

((17 - 13) / 13) * 100 = 30,7

Arredondamos:

VARIACAO_FINAL = 30 (porcento)

Ou seja, a variação percentual entre o pico do período observado com o teste de carga é 30%. 
Nossa aplicação, teoricamente apresentaria uma margem segura se trabalharmos 30% abaixo do limite de TPS calculado:

TPS = LIMITE_TPS * (VARIACAO_FINAL / 100)

ou

7 * (30 / 100) = 2,1

Arredondamos:

TPS = 2

Nossa aplicação que processa a fila deverá a cada 3 segundos, gerar 2 requisições no serviço onde fizemos o teste de carga. Ou seja, nós poderíamos trabalhar com 2 transações a cada 3 segundos para o processamento da nossa fila.

É isso. Creio que isso te ajude a chegar em um número adequado para um aumento de carga em uma aplicação que será consumida dentro de uma arquitetura distribuída.

Flw :D