Ao iniciar aplicações Spring Boot, normalmente usamos as configurações padrão fornecidas pelos starters, o que é suficiente para a maioria dos casos. No entanto, se estamos precisando de desempenho, há ajustes específicos que podem ser feitos, como será demonstrado na primeira parte deste artigo.

Substituindo o Tomcat por outro servlet container

Aplicações web, RESTFul, que utilizam o Spring MVC, geralmente adicionam a dependência spring-boot-starter-web, que por padrão utiliza o Tomcat como servidor web. Entretanto, existem alternativas mais interessantes, como o Undertow, que é um servidor web de alta performance, de arquitetura assíncrona e não-bloqueante, que permite lidar com um grande número de conexões simultâneas de forma eficiente, tornando-o adequado para aplicações de alto desempenho. Não estamos dizendo que o Tomcat é ruim, mas podemos dar uma chance para o Undertow.

Adicionando o Undertow no Spring

Para que utilizemos o Undertow como servidor web, precisamos ignorar a dependência spring-boot-starter-tomcat que o spring-boot-starter-web já adiciona e então adicionar o spring-boot-starter-undertow.

Utilizando pom.xml:

org.springframework.bootspring-boot-starter-weborg.springframework.bootspring-boot-starter-tomcatorg.springframework.bootspring-boot-starter-undertow

Utilizando build.gradle:

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-undertow'
}

Configurando o undertow

Através do application.properties ou o application.yml, podemos configurar quantas IO threads e quantas worker threads queremos que o servidor utilize.

Utilizando application.yml

server:
  undertow:
    threads:
      io: 4
      worker: 64

Utilizando application.properties

server.undertow.threads.io=4
server.undertow.threads.worker=64

I/O Threads executam operações não-bloqueantes e nunca devem realizar operações de bloqueio, pois são responsáveis por ouvir as conexões que chegam na aplicação, para então enviá-las para uma fila de processamento. Um valor comum é duas I/O Threads por núcleo de CPU.

Já as worker threads executam operações bloqueantes, como requisições Servlet que foram mandadas para a fila de processamento pelas I/O Threads. O valor ideal depende da carga de trabalho, mas geralmente é recomendado configurar cerca de 10 threads por núcleo de CPU.

Para informações mais detalhadas e mais opções que podem ser exploradas, basta ir na documentação do Undertow.

Comprimindo respostas HTTP

Compressão de dados é uma funcionalidade visa reduzir o tamanho do corpo das respostas HTTP, que por sua vez, pode melhorar o desempenho da nossa aplicação ao reduzir a quantidade de dados transmitidos pela rede.

Configurar compressão de dados no Spring Boot é uma tarefa trivial, por ele trazer suporte a essa funcionalidade.

Utilizando application.yml

server:
  compression:
    enabled: true
    mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
    min-response-size: 1024

Utilizando application.properties

server.compression.enabled=true
server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
server.compression.min-response-size=1024

server.compression.enabled: Habilita/desabilita a compressão.
server.compression.mime-types: Lista dos MIME types que devem ser comprimidos.
server.compression.min-response-size: Tamanho mínimo do "Content-Length" que é necessário para a compressão ser feita.

Com isso, fechamos a primeira parte do artigo. Na próxima parte, vamos conhecer melhor o Hikari, JPA e o Hibernate e aprender a configurá-los, afim de melhorar ainda mais o desempenho de aplicações Spring Boot.