DEV Community: marcelmfa

Estudo sobre HTTP2 e protocolos binários - parte 4

marcelmfa — Wed, 03 Aug 2022 19:27:27 +0000

Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:

Parte 1

Parte 2

Parte 3

Parte 4 Você está aqui.

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.

Estudo sobre HTTP2 e protocolos binários - parte 3

marcelmfa — Tue, 05 Jul 2022 19:44:46 +0000

Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:

Parte 1

Parte 2

Parte 3 Você está aqui.

Parte 4

Após um "longo" período após o último post, voltamos pra continuar com esta série. Conforme combinado no post anterior, iremos neste apenas alterar o servidor embarcado - isto é, mudar do padrão que é o Tomcat para o Undertow - que é usado pela aplicação e reexecutar os testes.

De acordo com o post anterior, já estamos "macetados", já sabemos todos os "paranauê" de acordo, então este post visa ser bem rápido.

Alterando a aplicação

Abaixo temos toda a mudança que é necessária para usar o Undertow ao invés do Tomcat.

Isto acontece porque o Spring Boot usa uma estratégia "Opinativa" (o termo original em inglês é Opionionated, então sei se a tradução é a mais adequada), que em resumo vai tentar configurar o máximo de coisas possíveis a partir das dependências ou das propriedades de sua aplicação, removendo assim muito de código e configurações que muitas vezes precisamos fazer para cada aplicação.

Caso deseje saber mais sobre essa estratégia, clique aqui ou até mesmo na documentação oficial.

Vamos de benchmark

Os gráficos seguirão abaixo e da mesma forma como os que fizemos no post anterior.

HTTP 1.1 e profile 1

Ponto de vista cliente

Ponto de vista aplicação

HTTP 2 e profile 1

Ponto de vista cliente

Ponto de vista aplicação

HTTP 1.1 e profile 2

Ponto de vista cliente

Ponto de vista aplicação

HTTP 2 e profile 2

Ponto de vista cliente

Ponto de vista aplicação

Avaliação simplória dos resultados

Todas as execuções consumiram praticamente mesma quantidade de CPU, apenas 1. O profile 2 que possui dobro recursos computacionais em relação ao profile 1 não trouxe nenhum ganho de performance. O uso de HTTP2 processou em torno de 10 mil requisições a mais que com HTTP1.1 e chegando a marca de 100 mil requisições no teste realizado.

Um ponto interessante é que este processou mais requisições do que o Tomcat, que vimos no post anterior, em torno de 20k requisições a mais e considerando o profile 1.

No entanto, como costumamos dizer e dando uma de "advogado do diabo", o que sabemos e até mesmo não sabemos sobre o Undertow? Acredito que a comunidade Java e Spring já é tão acostumada ao Tomcat que já conhece vários de seus pontos que necessitam ajustes / tuning.

Portanto minha dica é: pesquisem bem antes de sair fazendo um shift de todas as suas aplicações de Tomcat para Undertow e façam testes como esse.

Pois bem, chegamos ao final deste post e gostaria de dizer que poderíamos continuar quase que indefinidamente, explorando outros servidores como Netty, o não reativo do Webflux, poderíamos empacotar como WAR e implantar num servidor de aplicação Jboss, por exemplo, com outros frameworks de outras linguagens, etc.

Para não ficarmos neste loop infinito, vou apenas incluir os fontes das aplicações e as imagens dos benchmarks com os cenários que testei no repositório e lá vocês podem conferir a vontade.

Próximo post a gente vem brabo e de, finalmente, gRPC.

Estudo sobre HTTP2 e protocolos binários - parte 2

marcelmfa — Thu, 23 Jun 2022 21:11:50 +0000

Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:

Parte 1

Parte 2 Você está aqui.

Parte 3

Parte 4

Recomendações (Opcional)

Listo aqui algumas recomendações que podem ajudar vocês:

Se você usa Windows, eu recomendo que usem o WSL2 com alguma distro de sua preferência, caso goste ou queira testar o Ubuntu, só seguir este artigo, que possui um passo a passo bem intuitivo;
SDKMAN para gerenciar várias versões de vários softwares, dentre eles JDK, e até mesmo alterar qual versão quer usar. Aproveite e já instale o Java 11;
a IDE eu não vou opinar, pois vai muito de gosto pessoal, mas eu uso VSCode com algumas extensões do Spring, Java e para o WSL.

Criando aplicação Java + Spring Boot

Como iremos criar uma aplicação Spring Boot, obviamente iremos usar o site oficial para gerar o boilerplate inicial e já configurado com algumas dependências. Existe também o CLI e plugins em algumas IDEs que fazem o mesmo, mas o site acredito que seja o mais atualizado.

Nesta parte é importante apenas selecionar a opção "Java 11" e incluir as seguintes dependências:

Spring Web;
Spring Boot Actuator;
Prometheus.

Mas porquê adicionar essas dependências?

Estas dependências servem respectivamente para criar uma aplicação com um servidor web embarcado que iremos expor a API, seguindo de outras dependências que irão expor métricas desta aplicação.

E agora sem mais delongas.

Criando a API

Como dito no post anterior, iremos usar a lib Java Faker e o código está representado abaixo.

Ô amigão, o código fonte tá como imagem. Tu tá de brinqueichon uite me?

Na seção final irei deixar o link do repositório no Github.

Habilitando HTTP2

Como já é hábito (cof cof, ou pelo menos a gente tenta XD), na hora de verificar como configurar determinada funcionalidade em um framework / biblioteca / ferramenta vamos de documentação oficial e na seção específica que trata do assunto.

Como lido na documentação e trazendo de forma bem curta e ligeira, para habilitar HTTP2 será necessário também configurar o TLS desta aplicação, que por sua vez será necessário um certificado, donde usaremos um auto-assinado conforme abaixo.

keytool -genkeypair -alias spring-http2 -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore spring-http2.p12 -validity 3650

E use a senha passwd quando solicitado e copiar o arquivo criado para a pasta src/main/resources/keystore na aplicação.

PS.: Estamos colocando o certificado dentro da aplicação apenas para fins de simplicidade e demonstração, mas o mesmo deveria estar externalizado.

Abaixo as propriedades da aplicação.

A última propriedade é referente a exposição de endpoints do actuator, que para efeitos de simplicidade foram expostos todos para que o Prometheus possa fazer o scrapper destes dados e assim termos monitoramento da aplicação.

As demais propriedades são relacionadas a HTTP2, HTTPS e certificado.

Caso queira testar a aplicação, pode-se usar o Maven wrapper que vem junto ao projeto do Spring e rodar a aplicação da seguinte forma:

./mvnw spring-boot:run

Depois pode-se acessar os seguintes endpoints:

Beleza galera, agora foi a parte demorada, agora vai ser à jato.

Instalar ferramentas - Prometheus, Grafana, InfluxDB1 e k6

Vamos rever a nossa arquitetura de benchmark que foi apresentada no post anterior, mas está logo aqui abaixo para facilitar o rolê.

Vamos instalar o Prometheus, Grafana, InfluxDB1 e k6 e aqui não tem muito mistério pessoal, iremos usar as instruções de instalação e execução de acordo com o site de cada ferramenta conforme os links abaixo:

Configurando as ferramentas

Com todas as ferramentas instaladas, agora iremos verificar como configurar cada uma delas.

Configurando a aplicação

Como temos 2 profiles, então teremos que iniciar a aplicação de forma diferente a cada teste:

2cpu, 2Gb RAM - cujo comando será:

./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-XX:ActiveProcessorCount=2 -Xmx2g -Xms2g"

4cpu, 4Gb RAM - cujo comando será:

./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-XX:ActiveProcessorCount=4 -Xmx4g -Xms4g"

Foi incluído o trecho de código abaixo para exibir esses valores de CPU e memória durante a inicialização da aplicação, apenas para confirmar:

Configurando o Prometheus

No caso do prometheus, precisa apenas iniciar o serviço com um arquivo de configuração para que o mesmo possa ler as métricas da aplicação. Segue abaixo um exemplo de scrapper de métricas para esta aplicação em específico.

Configurando InfluxDB1

Nada aqui, apenas iniciar o serviço.

Configurando Grafana

Inicie o serviço do Grafana, abra sua interface web, faça login com tanto usuário e senha admin e em seguida vamos configurar 2 itens: data sources e dashboards.

Data sources

Para incluir os data sources, pode-se na tela inicial, vai ter um card para adicionar o data source ou pode-se ir no menu lateral.

Para o Prometheus basta colocar a URL do mesmo http://localhost:9090/ e se o serviço estiver rodando, pode salvar e testar.

Para o InfluxDB é necessário colocar a URL do mesmo http://localhost:8086 e informar no campo mais abaixo Database o valor myk6db, cujos valores serão utilizados na próxima seção para o k6 fazer a ingestão das métricas.

Dashboards

Quando estava visitando artigos e a própria documentação do Grafana, notei que existe lá no site oficial uma seção onde as pessoas compartilham dashboards, então usando o conceito de "Não reinvente a roda", então pensei: "deixa eu ver se num já tem um giga painel completão de tudo".

E a grande motivação de eu ter usado o InfluxDB1 foi justamente por ter encontrado um dashboard pronto pro k6 de id 4411. Quanto ao Spring Boot também achei um muito bacana de id 14430.

Para importar esses dashboards, basta vir no menu lateral, no ícone de + e ir na opção Import. Só usar os Ids acima e clicar no Load.

Estes serão os dashboards apresentados no benchmark.

Configurando k6

Como iremos executar um comparativo entre HTTP1.1 e HTTP2, além de que também teremos métricas de cliente e que sejam enviadas para o InfluxDB, então faremos a execução da seguinte forma:

HTTP1.1

GODEBUG=http2client=0 k6 run ./k6/http_get.js -o influxdb=http://localhost:8086/myk6db

HTTP2

k6 run ./k6/http_get.js -o influxdb=http://localhost:8086/myk6db

Como é possível perceber acima, o comando é praticamente o mesmo, porém conforme a documentação, o k6 por padrão tenta executar sempre usando HTTP2, então é necessário forçar o mesmo a usar o HTTP1.1 passando um parametro pro Go.

O comando acima referencia um aquivo JS que é como o k6 faz as execuções. Abaixo o tal arquivo que define o teste e este foi criado seguindo o exemplo de teste de carga (Load Test) da documentação oficial.

Agora finalmente, temos todos os serviços instalados e sabemos como executar cada um deles para começar as execuções.

O famigerado benchmark

Agora que instalamos tudo, sabemos como iniciar cada serviço, vem a sequência de execuções.

Iremos priorizar a mudança de protocolo diante um profile e então mudaremos para o próximo profile.

Faremos na seguinte sequência:

HTTP1.1 e profile 1
HTTP2 e profile 1
HTTP1.1 e profile 2
HTTP2 profile 2

Organizei desta forma para ficar mais fácil de visualizar os testes de cada profile. Os resultados a seguir serão sempre exibidos com os resultados do lado do cliente e depois da aplicação para cada um dos testes.

PS.: Os resultados abaixo são os mesmos que preparei para uma apresentação para colegas do trabalho. Realizei todos os testes na minha máquina mesmo para efeitos de demonstração, que devem ser realizados em um ambiente adequado sem que os serviços fiquem competindo entre si.

HTTP1.1 e profile 1

Ponto de vista cliente

Ponto de vista aplicação

HTTP2 e profile 1

Ponto de vista cliente

Ponto de vista aplicação

HTTP1.1 e profile 2

Ponto de vista cliente

Ponto de vista aplicação

HTTP2 e profile 2

Ponto de vista cliente

Ponto de vista aplicação

Avaliação simplória dos resultados

Analisando ambas execuções do profile 1 para HTTP1.1 e HTTP2 os resultados foram praticamente os mesmos, considerando número de requisições, tempos de resposta, uso de CPU e memória.

Comparando ambas execuções do profile 2 os resultados foram similares à análise anterior.

Ao comparar as execuções dos profiles 1 e 2, esta respondeu em torno de 10 mil requisições a mais (ou seja, a performance aumentou dado que o tempo de exeução é o mesmo para todos os testes) e consumiu mesma quantidade de CPU do que a do profile 1.

Para este caso de uso específico, não houve ganho com uso de HTTP2, mas qual seria o problema (se é que tem algum):

falta de tuning?
caso de uso não adequado?
teria alguma falha no teste de carga?
O uso da mesma máquina para rodar tudo?

Essas e outras perguntas podem surgir durante uma avaliação e acredito ser normal. Resta continuar estudando essa disciplina de engenharia de desempenho para tentar elucidar todas as questões acima.

Considerações finais

Apenas reforçando o que foi dito anteriormente e para que ninguém considere este resultado uma verdade absoluta:

Os testes, incluindo todas as ferramentas, foram TODOS executados na minha máquina competindo entre si pelos recursos, incluindo o SO;
O caso de uso específico tem uma quantidade mínima de processamento, apenas gerar 100 itens e retornar; não possui nenhuma dependência de recurso / serviço externo seja I/O ou de rede;
Não foi aplicada nenhuma configuração de tuning em nenhum dos elementos, foram mantidas todas as configurações padrão.

Enfim, espero não ter sido demasiadamente longo neste post e que tudo apresentado aqui sirva de ajuda ou exemplo para que vocês possam usar de alguma forma no dia a dia.

As imagens ficaram pequenas aqui, mas irei incluir as mesmas no repositório caso queiram ver os originais.

Por falar em repositório, clique aqui para ver o código fonte.

FUTURO!?!?

Após este trabalho realizado e apresentado, um colega do trabalho mandou um: "E se a gente testar também com Undertow?".

Nos vemos na próxima parte, com os testes no Undertow.

[Atualizado 24/06] - Incluída configuração de Data Sources e IDs dos dashboards.

Estudo sobre HTTP2 e protocolos binários - parte 1

marcelmfa — Fri, 17 Jun 2022 20:32:31 +0000

Este post faz parte da seguinte série sobre estudo de HTTP2 e protocolos binários:

Parte 1 Você está aqui.

Parte 2

Parte 3

Parte 4

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?

Eu cheguei a ler artigos como este, 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 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. Testei umas 3 delas e por último cheguei no k6 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.

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:

2cpu, 2Gb RAM
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.