Estudo sobre HTTP2 e protocolos binários - parte 3
Tags: performance, http2, java, monitoring
Published: 2022-07-05 19:44:46

> 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) Você está aqui.
> - [Parte 4](https://dev.to/marcelmfa/estudo-sobre-http2-e-protocolos-binarios-parte-4-2fkc)

![Após um longo período](https://i.gifer.com/UNm2.gif)

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.

![Rápido como Sonic](https://c.tenor.com/d2YGFjEazDgAAAAC/run-fast.gif)

## Alterando a aplicação

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

![Isto](https://c.tenor.com/ampW8g8v-vMAAAAd/hack-khaby.gif)

![Alterações no pom.xml](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c1lroj52o84t1brhdk2h.png)

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](https://www.fusion-reactor.com/blog/technical-blogs/what-is-spring-boot/#:~:text=Spring%2DBoot's%20Opinionated%20Defaults%20Configuration,based%20on%20the%20dependencies%20requirement.) ou até mesmo na [documentação oficial](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started.introducing-spring-boot).

## Vamos de benchmark

![Lá vamos nós](https://media2.giphy.com/media/LpkBAUDg53FI8xLmg1/giphy.gif)

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

![Resultados para ponto de vista cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ctbktjr4betzw6jy6tbz.png)

Ponto de vista aplicação

![Resultados para ponto de vista aplicação](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wj6q8m2lhybmf63yw6bh.png)

### HTTP 2 e profile 1

Ponto de vista cliente

![Resultados para ponto de vista cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ynri9wmibpcfxjp1fhk4.png)

Ponto de vista aplicação

![Resultados para ponto de vista aplicação](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ag08l2f14jq9xadgswss.png)

### HTTP 1.1 e profile 2

Ponto de vista cliente

![Resultados para ponto de vista cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7inrim7qz4n3obvxorfx.png)

Ponto de vista aplicação

![Resultados para ponto de vista aplicação](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ydjzk733cg9hkc1oubjr.png)

### HTTP 2 e profile 2

Ponto de vista cliente

![Resultados para ponto de vista cliente](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3mvccj5de9gxdx4cv9h3.png)

Ponto de vista aplicação

![Resultados para ponto de vista aplicação](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sr2gifgeccbhqkgn3qij.png)

## 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.

![Cena do filme advogado do diabo](http://2.bp.blogspot.com/-oP7GIovKL5I/ViDvzDdxaaI/AAAAAAAAcfo/c37NjBamRIc/s1600/fhd997TDA_Keanu_Reeves_032.jpg)

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.

![E se trocarmos tudo por Undertow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/az9z19kbmoqym3bhiajh.png)
 

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](https://github.com/marcelmfa/estudo-http2-grpc) e lá vocês podem conferir a vontade.

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

![Continue comigo](https://i2.wp.com/parafraseandolivros.com.br/wp-content/uploads/2018/04/come-with-me.gif?fit=500%2C269&ssl=1)