Por Gabriel Prestes*

Quando provisionamos infraestrutura para uma API ou WebServices de integração sabemos que performance é um dos, senão o principal, fator a ser considerado, pois estamos trabalhando com um alto fluxo de requisições. A degradação de performance para este tipo de aplicação significa ao longo de um período sua indisponibilidade, pois ao não atender a carga eficientemente acumulam-se mais requisições de origem criando uma retenção que gerará aumento do tempo de resposta.

TomcatQuando um WebService, ou API, é desenvolvido em Java temos algumas alternativas para fazer sua exposição web. Criá-lo autocontido em um JAR com Jetty, publicar em um servidor de aplicação são algumas das diversas opções disponíveis. Neste texto, consideramos que a publicação foi feita em um Tomcat ou TomEE, ou até mesmo em um servidor de aplicação que utiliza o Tomcat como contêiner Web, exemplo JBoss, que tem até a versão 6 o JBoss Web.

A Apache Foundation disponibiliza para o Tomcat como biblioteca de suporte a alta performance, escalabilidade e integração o Apache Portable Runtime,  suporte que só estará ativo quando três componentes forem identificados na inicialização da JVM do Tomcat:

1 – APR – Apache Portable Runtime;

2 – JNI wrappers para o APR -> (libtcnative);

3 – OpenSSL.

Mas qual o ganho real com isso?

HTTP

Ganho de 11% em requisições HTTP quando utilizado o APR ao invés do connector BIO (padrão) e somente 7% a menos que um Apache 2.x.  

HTTPS

Ganho de mais de 100% em requisições HTTPS quando se substitui o connector padrão do Tomcat pelo APR, performando inclusive melhor a um WebServer Apache 2.x.

Veja o benchmark mais detalhado aqui.

Fique ligado: ter tais componentes instalados no sistema operacional nem sempre indica que o APR está sendo carregado corretamente no Tomcat. No CentOS ou RHEL (RedHat Enterprise Linux) 6 ou 7, por exemplo, o APR instalado não é identificado pela libtcnative, o que por consequência inviabiliza o uso do APR no Tomcat.

Forma de identificar que o Tomcat não está utilizando o APR é avaliar o log do Catalina quando em severidade INFO ou menor:

org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

Algumas abordagens mais atuais de arquitetura reduzem o impacto de baixa performance escalando horizontalmente a infraestrutura, ainda assim, quanto menor a capacidade de processamento, maior a quantidade de servidores que precisará escalar para ter vazão.  

Dependendo do tipo de negócio que é aplicado, uma API ou WebService não ser utilizado por questão de ineficiência de tempo de resposta é fadar a aplicação ao fracasso.

Referências:

https://tomcat.apache.org/tomcat-8.0-doc/apr.html
https://blog.eveoh.nl/2012/04/some-notes-on-tomcat-connector-performance/

Fonte imagem: http://tomcat.apache.org/

 

1527118_559096640840386_1699822479_n*Gabriel Prestes é formando em Gestão da Tecnologia da Informação e atua como arquiteto de middleware na ilegra. Tem experiência de mais de 5 anos em suítes de middleware Oracle e RedHat. É um entusiasta de carros antigos.

Tagged on:         

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

CAPTCHA
Change the CAPTCHA codeSpeak the CAPTCHA code