Quando provisionamos infraestrutura para uma API ou WebServices de integracao sabemos que performance e um dos, senao o principal, fator a ser considerado, pois estamos trabalhando com um alto fluxo de requisicoes. A degradacao de performance para este tipo de aplicacao significa ao longo de um periodo sua indisponibilidade, pois ao nao atender a carga eficientemente acumulam-se mais requisicoes de origem criando uma retencao que gerara aumento do tempo de resposta. Quando um WebService, ou API, e desenvolvido em Java temos algumas alternativas para fazer sua exposicao web. Cria-lo autocontido em um JAR com Jetty, publicar em um servidor de aplicacao sao algumas das diversas opcoes disponiveis. Neste texto, consideramos que a publicacao foi feita em um Tomcat ou TomEE, ou ate mesmo em um servidor de aplicacao que utiliza o Tomcat como conteiner Web, exemplo JBoss, que tem ate a versao 6 o JBoss Web. A Apache Foundation disponibiliza para o Tomcat como biblioteca de suporte a alta performance, escalabilidade e integracao o Apache Portable Runtime, suporte que so estara ativo quando tres componentes forem identificados na inicializacao 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? HTTPGanho de 11% em requisicoes HTTP quando utilizadoo APR ao inves do connector BIO (padrao) e somente 7% a menos que um Apache 2.x. HTTPSGanho de mais de 100% em requisicoes HTTPS quandose substitui o connector padrao 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 esta sendo carregado corretamente no Tomcat. No CentOS ou RHEL (RedHat Enterprise Linux) 6 ou 7, por exemplo, o APR instalado nao e identificado pela libtcnative, o que por consequencia inviabiliza o uso do APR no Tomcat. Forma de identificar que o Tomcat nao esta utilizando o APR e 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 precisara escalar para ter vazao. Dependendo do tipo de negocio que e aplicado, uma API ou WebService nao ser utilizado por questao de ineficiencia de tempo de resposta e fadar a aplicacao ao fracasso. Referencias:https://tomcat.apache.org/tomcat-8.0-doc/apr.htmlhttps://blog.eveoh.nl/2012/04/some-notes-on-tomcat-connector-performance/Publicacao tambem disponivel em: http://ilegra.com/beyonddata/ Um dia o gerente de desenvolvimento chega a sua mesa e reporta que a era do seu Oracle Application Server (OAS) 10g chegou ao fim. Ele valoriza um relatorio objetivo e visualmente agradavel com analise de impacto de negocio bem enumerada e suficiente para que a renovacao ou atualizacao de licenciamento seja uma necessidade imediata. E se e voce que precisa entregar este relatorio bem fundamentado, quais os pontos para chegar a tal conclusao? Alem disso, como atraves de diferencas tecnicas voce podera