Estudo sobre HTTP2 e protocolos binários - parte 4
Tags: grpc, java, monitoring, performance
Published: 2022-08-03 19:27:27

> Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:
> - [Parte 1](https://dev.to/marcelmfa/estudo-sobre-http2-e-protocolos-binarios-parte-1-5h9o) 
> - [Parte 2](https://dev.to/marcelmfa/estudo-sobre-http2-e-protocolos-binarios-parte-2-3m8l) 
> - [Parte 3](https://dev.to/marcelmfa/estudo-sobre-http2-e-protocolos-binarios-parte-3-5f9k) 
> - [Parte 4](https://dev.to/marcelmfa/estudo-sobre-http2-e-protocolos-binarios-parte-4-2fkc) Você está aqui.

Antes de começarmos gostaria de lhes pedir para dar uma lida rápida sobre o gRPC da [documentação oficial](https://grpc.io/docs/what-is-grpc/introduction/).

> Mas, meu amigo, tu acha mesmo que eu sei inglês?

![Desculpa, eu não sei inglês](https://c.tenor.com/ZCpVUbRJs24AAAAC/sorry-i-dont-speak-english-wwe.gif)

Beleza meu patrão, então faça como fiz um tempo atrás e leia pelo menos este [primeiro post](https://blog.lsantos.dev/guia-grpc-1/) do blog do [Lucas Santos](https://twitter.com/_staticvoid). 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:

1. É um protocolo que segue um *schema* ([**Protocol Buffers**](https://developers.google.com/protocol-buffers/docs/overview)) de dados que define como são as entradas e saídas, *messages*;
1. 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;
1. 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](https://developers.google.com/protocol-buffers/docs/overview#work).

> Tá nice, já entendi o básico, mas e agora?

![Ok e agora?](https://c.tenor.com/4eO9HfdsmZcAAAAM/shauny-shirley.gif)

Agora vamos ao planejamento das atividades, que são:

1. Criar a nova aplicação Spring (claro!) com gRPC;
1. Criar novo script para o k6 para fazer o benchmark;
1. Criar um novo dashboard para visualizar estas métricas (será explicado a seguir);
1. Realizar o *benchmark*.

# Criando a aplicação Spring com gRPC

Primeiramente fui a [documentação oficial do Spring Boot](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/) e achei "ZERO" referências a gRPC.

Aí já fiquei com aquele sentimento: "Vixe..."

![Vixe](https://c.tenor.com/FWHNaNZkR7gAAAAM/baby-roller-coaster.gif)

Olhando a [documentação oficial do gRPC pra Java](https://developers.google.com/protocol-buffers/docs/javatutorial), 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](https://github.com/yidongnan/grpc-spring-boot-starter), como o cara também fez um [site EXCEPCIONAL](https://yidongnan.github.io/grpc-spring-boot-starter/en/), 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](https://yidongnan.github.io/grpc-spring-boot-starter/en/server/getting-started.html#server-project).

Olhando na parte de [*setup*](https://yidongnan.github.io/grpc-spring-boot-starter/en/server/getting-started.html#project-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](https://k6.io/blog/performance-testing-grpc-services/#getting-started) 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](https://k6.io/docs/javascript-api/k6-net-grpc/), 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.

![Alívio](https://c.tenor.com/g_d3iHyzc68AAAAM/hammaya-relaxed.gif)

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.

![Confuso](https://media1.giphy.com/media/AfXPYfexaPjPsEdsUz/200.gif)

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

![Resultados da visão do cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wj8q12z6nnriqj7cykvz.png)

Visão da JVM do servidor

![Resultados da visão da JVM](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kdyzcj4vsfi0yepgyb1o.png)

Visão de gRPC do servidor

![Resultados da visão gRPC do servidor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xy50dpzs1zz5g3ma51c0.png)

## Profile 2

Visão do cliente

![Resultados da visão do cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iohgiq1a19y6hsyf5u5y.png)

Visão da JVM do servidor

![Resultados da visão da JVM](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y6foeh4qv78vmwo6dw4a.png)

Visão de gRPC do servidor

![Resultados da visão gRPC do servidor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nik2k5l7jfhjwzdzyyz4.png)

# 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](https://community.k6.io/t/grpc-limited-metrics/1902/2). 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](https://github.com/marcelmfa/estudo-http2-grpc) assim como arquivos de configuração.

Nos vemos na próxima série ou tópico.

![Isso é tudo pessoal](https://c.tenor.com/-GnZ6NOpsXkAAAAC/thats-all-folks.gif)