Estudo sobre HTTP2 e protocolos binários - parte 1
Tags: performance, http2, java, monitoring
Published: 2022-06-17 20:32:31

> 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) Você está aqui.
> - [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)

Estava iniciando junto a colegas do trabalho um estudo sobre o uso de protocolos binários como gRPC e MessagePack a fim de experimentar e avaliar os mesmos em termos de uso e performance, porém algo antes nos incomodou, que é sobre o uso do HTTP2, que tais protocolos fazem uso.

E a pergunta que surgiu foi:

> E se antes de experimentarmos esses protocolos, a gente avaliasse o uso de HTTP2 e comparar com o HTTP1.1?

![A gente pensando](https://c.tenor.com/-HfTRwXMWT0AAAAC/kid-thinking.gif)

Eu cheguei a ler artigos como [este](https://evertpot.com/h2-parallelism/), que é bem completo, mas acho que ele trata mais do ponto de vista dos *browsers*, ou seja, quando alguém acessa um site e como ele se comporta para "baixar" (realizar o *download*) de todos aqueles recursos.

O ponto de vista que eu tava imaginando seria serviço a serviço, algo interno da infraestutura dos produtos, ou seja, seria um consumo lateral de serviços. Dado que era um cenário diferente do artigo supracitado, veio a idéia de criar o meu próprio *benchmark*.

Beleza então, já tava decidido sobre o "benchmark", agora o lance é planejar como vai ser esse trabalho. Vou precisar de:

- uma aplicação obviamente que vai ter que se comunicar via HTTP1.1 e HTTP2 com o mínimo de alterações e idealmente nenhuma;
- um *client* para realizar esse *benchmark* e que obviamente possua suporte a HTTP1.1 e HTTP2;
- algo pra monitoramento, que receba as métricas e que eu possa visualizar as mesmas.

Como a linguagem que mais domino é Java e sou um fã / enorme entusiasta do Spring, já ficou fechada essa parte. A aplicação é uma API REST com um recurso GET que retorna uma lista de dados em JSON. Utilizamos o [Java Faker](https://github.com/DiUS/java-faker) para gerar os dados em runtime, incluí-los numa lista de um POJO e retornar ao solicitante. Pensamos nesta forma para não um retorno de algo estático e ter um mínimo processamento.

Quanto ao *client*, comecei a pesquisa no amigo de todo dia, Google, e me deparei com essa ["pequena" lista de ferramentas](https://github.com/denji/awesome-http-benchmark). Testei umas 3 delas e por último cheguei no [k6](https://k6.io/docs/) que pra minha surpresa é do Grafana Labs.

Quanto ao monitoramento, onde trabalho estamos investindo e usando Prometheus e Grafana, então veio tudo a calhar com a escolha do k6, que já tem toda uma documentação pronta e com exemplos para esta integração.

Ficou fechado o esquema que seria da forma abaixo.

![Arquitetura do benchmark](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2k4ydkb54nhnrfec5g6h.png)

Podemos ver acima que tem um cara novo e que não citado anteriormente, que é o Influx. Este camarada apareceu aí porque olhando site do Grafana, lá tem vários dashboards prontos e tinha um do k6, porém usava o Influx como base de métricas, então incluí o mesmo para facilitar o trabalho.

Por fim, como vai ser realizado um trabalho de monitoramento e como o foco deste trabalho seria em cima de máquinas virtuais, então pensamos em estabelecer uma cota de recurso e daí veio a idéia de 2 profiles:

1. 2cpu, 2Gb RAM
2. 4cpu, 4Gb RAM

O Java 11 possui tais argumentos de VM para poder incluir estas cotas.

Bem, este foi apenas o primeiro post tanto deste estudo como meu próprio.

Abaixo uma imagem ilustrativa de como pode ser o próximo post.

![Cenas dos próximos capítulos](https://i.gifer.com/1Cr1.gif)