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.
Quando 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.
|
Benchmark mais detalhado em : https://blog.eveoh.nl/2012/04/some-notes-on-tomcat-connector-performance/
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:
Publicação também disponível em: http://ilegra.com/beyonddata/
