... | ... | @@ -70,9 +70,9 @@ O endpoint que processa as requisições enviadas na rota `/webhooks/rest/webhoo |
|
|
Note que nessa implementação o endpoint congela a execução na chamada do método `on_new_message`. É nesse ponto que cada thread vai aguardar o rasa processar o texto enviado pelo usuário. Assim que a mensagem é enviada de volta pelo rasa o endpoint encerra sua execução e a thread é removida. Os cenários de teste a seguir irão disparar requisições http no endpoint de webhook, enviando no body algum texto a ser respondido pelo bot. A meta dos cenários é prover insumos para que recursos de infraestrutura possam ser dimensionados a partir de dois critérios chaves:
|
|
|
|
|
|
1. O volume médio de acessos simultâneos esperado.
|
|
|
2. O tempo de resposta, que aqui iremos definir como três segundos.
|
|
|
2. O tempo de resposta que será aceitável quando for próximo de três segundos.
|
|
|
|
|
|
A partir do resultado de cada cenário, iremos calibrar os fatores como o número de instâncias da api, consumo de RAM e CPU para que o tempo de resposta se mantenha próximo a três segundos.
|
|
|
A partir do resultado de cada cenário, iremos calibrar os fatores como o número de instâncias da api, consumo de RAM e CPU para que o tempo de resposta se mantenha próximo ao experado.
|
|
|
|
|
|
## Cenario 1
|
|
|
|
... | ... | @@ -82,16 +82,16 @@ A partir do resultado de cada cenário, iremos calibrar os fatores como o númer |
|
|
|
|
|
![teste_1_jmeter](uploads/e39712b5361c1766818b8c5d2369a841/teste_1_jmeter.png)
|
|
|
|
|
|
No primeiro cenário simulamos um usuário enviando quatro mensagens para o Rasa. O relatório do JMeter indica que todas as mensagens tiveram um tempo de resposta entre 0.5 segundos e 1.5 segundos. Nesse cenário temos apenas uma instância do rasa sendo exeuctada. O recurso de memória utilizado não foi customizado, é o valor padrão definido pelo kubernetes.
|
|
|
No primeiro cenário simulamos um usuário enviando quatro mensagens para o Rasa. O relatório do JMeter indica que todas as mensagens tiveram um tempo de resposta entre 0.5 segundos e 1.5 segundos. Nesse cenário temos apenas uma instância do rasa sendo exeuctada. O recurso de memória utilizado não foi customizado sendo o valor padrão definido pelo kubernetes.
|
|
|
|
|
|
|
|
|
## Cenario 1
|
|
|
## Cenario 2
|
|
|
|
|
|
| nº de acessos simultâneos | nº de instâncias | RAM (mb) por instância |
|
|
|
| ------ | ------ | ------ |
|
|
|
| 30 | 1 | 300 |
|
|
|
| 10 | 1 | 300 |
|
|
|
|
|
|
|
|
|
![flotTimesVsThreads](uploads/4e72c40899002c4be90e1811423a291e/flotTimesVsThreads.png)
|
|
|
|
|
|
|
|
|
Podemos verificar que o Senic manteve o tempo de resposta de cada thread dentro de uma faixa de 12.5 segundos, o que é um indício de que apesar de terem sido disparadas ao mesmo tempo, todas foram processadas de maneira assíncrona. Um segunda ponto é que todas as 30 requisições foram processadas, e a api retornou um response válido para todas.
|
... | ... | |