Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:
Antes de começarmos gostaria de lhes pedir para dar uma lida rápida sobre o gRPC da documentação oficial.
Mas, meu amigo, tu acha mesmo que eu sei inglês?
Beleza meu patrão, então faça como fiz um tempo atrás e leia pelo menos este primeiro post do blog do Lucas Santos. Na boa, lê os demais também, o material tá muito bom e se você está estudando NodeJS então, melhor ainda.
Da rápida leitura que fizemos do material acima conseguimos entender que:
- É um protocolo que segue um schema (Protocol Buffers) de dados que define como são as entradas e saídas, messages;
- O schema citado anteriormente não pertence a domínio de linguagem específica, porém necessita de implementações específicas de cada linguagem que possam implementar o contrato (schema) citado no item anterior;
- Esta implementação específica irá abstrair a parte de serialização e deserialização destes dados, permitindo que a aplicação faça apenas o preenchimento dos dados como neste exemplo.
Tá nice, já entendi o básico, mas e agora?
Agora vamos ao planejamento das atividades, que são:
- Criar a nova aplicação Spring (claro!) com gRPC;
- Criar novo script para o k6 para fazer o benchmark;
- Criar um novo dashboard para visualizar estas métricas (será explicado a seguir);
- Realizar o benchmark.
Criando a aplicação Spring com gRPC
Primeiramente fui a documentação oficial do Spring Boot e achei "ZERO" referências a gRPC.
Aí já fiquei com aquele sentimento: "Vixe..."
Olhando a documentação oficial do gRPC pra Java, só é possível ver coisas relacionadas ao schema (arquivo .proto), ao compilador deste esquema (protoc), configurações deste compilador, ao código gerado e um exemplo bem simples usando o código gerado.
Repete o "Vixe..." aí de cima.
O jeito então foi ampliar a pesquisa (Google) para ver se existe algo específico com gRPC e Spring, donde acabo caindo não só num repositório, como o cara também fez um site EXCEPCIONAL, diga-se de passagem e - para quem já é acostumado ao ecossitema Spring Boot - o caboco ainda criou um artefato starter conforme pode ser observado na declaração do pom.
Olhando na parte de setup é possível perceber que teremos agora pelo menos 2 projetos:
- o projeto Interface que é responsável por conter o contrato e o código gerado pelo compilador do gRPC (protoc), donde geraremos um JAR para reutilizado em outros projetos que queiram se comunicar usando este contrato;
- e o projeto Server que irá servir o contrato do projeto Interface gerado no item anterior.
Neste caso especificamente usaremos o k6 como Client, então não teremos outra aplicação Java reusando o projeto Interface.
Vamos ao próximo tópico.
Criar script k6 pro gRPC
Esta parte foi tão fácil quanto criar os scripts para o HTTP(S), pois eles tem um artigo no próprio blog deles sobre o assunto.
Então bastou pouquíssimas alterações.
Métricas e Dashboard no Grafana
Neste tópico surgem alguns pequenos problemas:
- Conforme visto no link no item anterior, diferentemente do HTTP temos pouquíssimas métricas para o gRPC, que são de dados trafegados, duração, iterações e VUs. No entanto, a documentação cita que este módulo está em beta, então esperemos mudanças para melhorar a observabilidade;
- Por ter métricas diferentes e até mesmo nomes diferentes, precisaremos customizar o dashboard do k6 usado do HTTP;
- Da mesma forma que no client side, o mesmo ocorre no lado do servidor e lá também encontramos uma deficiência semelhante às métricas fornecidas, então criaremos também um dashboard específico dado que são pouquíssimas métricas.
Porém, depois de uma pequena tempestade, vem o alívio.
Não se preocupe, que estes dashboards estarão no repositório para serem importados. Além do mais, a parte da ingestão das métricas vai continuar sendo feita da mesma forma que nos posts anteriores. No client, o k6 continua enviando pro InfluxDB. No server, o Prometheus continua fazendo scrapping via HTTP.
Isto mesmo, nesta aplicação Server do gRPC teremos também um Tomcat embarcado para servir as métricas para o Prometheus via HTTP.
Benchmark
Diferentemente dos posts anteriores teremos apenas a execução dos profiles 1 (2cpu, 2Gb) e 2 (4 cpu, 4Gb).
Como citado anteriormente, criei um dashboard com as métricas do Server gRPC, então teremos 3 gráficos, sendo um do k6 (visão do client) e dois pro servidor, onde um com as métricas padrão do Actuator do Spring Boot e outro (criado do zero) apenas com as métricas específicas do gRPC.
Profile 1
Visão do cliente
Visão da JVM do servidor
Visão de gRPC do servidor
Profile 2
Visão do cliente
Visão da JVM do servidor
Visão de gRPC do servidor
Avaliação simplória dos resultados
No dashboards de visão do cliente não tem dados de requests per second dado que esta métrica não existe pro k6 com gRPC, que é inclusive comentado nos fóruns do Grafana. Porém conforme também dito anteriormente, esta API ainda está em Beta, então pode ser que algo mude no futuro.
A performance com profile 2 foi ligeiramente melhor (chegando próximo das 100 mil requisições), atendendo em torno de 5 mil requisições em relação a do profile 1, porém não é algo significativo dado que reservou o dobro de recursos.
Quanto ao uso de CPU, o uso se manteve em no máximo 1 para ambos os profiles. Quanto ao uso de memória não foi possível perceber nenhuma diferença significativa entre os profiles. Quanto às métricas de gRPC, a diferença significativa está no Max Duration que no profile 1 chegou a 4s por alguns períodos, enquanto que no profile 2 chegou a no máximo 3s.
The End!
Chegamos ao fim desta série e espero que possa ajudar ou ter ajudado você de alguma forma na sua jornada.
E aqui seguem os fontes assim como arquivos de configuração.
Nos vemos na próxima série ou tópico.
Top comments (0)