Tomcat: Rest in Peace?

{ October 10th, 2008 }

Autor: cmilfont

Ultimamente tenho lido o depoimento de uma gama enorme de profissionais sobre os problemas de Memory Leak do Tomcat e alguns levantam a hipótese de uma possível descontinuação.

Fábio Kung publicou no blog da Caelum sobre os problemas enfrentados pelo GUJ (maior e melhor fórum sobre Java e arquitetura de software do Brasil) de quedas e lentidão. Há poucos dias o Diego Plentz também publicou sobre experiência recente, até citando o artigo do Kung e dando explicações sobre as mudanças necessárias que teve que realizar nas aplicações durante a mudança do Tomcat para o Jetty.

Na Java Magazine desse mês, edição 61, o autor OSVALDO PINALI DOEDERLEIN - no artigo denominado “WTP 3.0 - Novidades do Ganymede para desenvolvimento Java EE” - escreveu no quadro: “Glassfish? Por que não Tomcat ou JBoss?”, o seguinte sobre o Tomcat:

O projeto Apache Tomcat não me parece ir bem. O Tomcat 6 (versão atual) só teve dois builds estáveis: o release inicial de 2007 e um único update. Houve defecção de colaboradores importantes “como pessoal da Sun, realocado para o Glassfish quando este começou a levantar vôo, e para outros projetos como o LWUIT. Tecnologicamente o Tomcat parou no tempo há um par de anos. Fez a opção de reusar o APR (biblioteca de código nativo do Apache HTTPD), ao invés de investir forte no caminho “puro Java” de APIs como java.nio - opção que o Glassfish provou ser superior. Não tem havido atualizações de correção & segurança com a regularidade que considero necessária para software dessa natureza. Continuo considerando o Tomcat uma boa opção apenas para ambientes onde toda a comunicação HTTP tem que passar pelo Apache HTTPD.

….

É interessante observar que o Tomcat é o container web embutido no JBoss, e o JBoss é outro colaborador importante do projeto Tomcat. O que possivelmente indica que as dificuldades de ambos os projetos possam estar relacionadas.

Com a onda crescente do Jetty sobre a base instalada do Tomcat é possível que nos próximos meses os retardatários movam seus sistemas jogando a última pá de terra.

E vocês? Já estão usando o Jetty em alternativa ao Tomcat?

Posted in High Performance, JEE, Jetty, Melhores práticas, Tomcat ~ 3 Comments

Compare a velocidade dos seus sites

{ July 19th, 2008 }

Autor: cmilfont

O Webslug é um serviço onde você pode comparar a velocidade de carregamento do seu site com outro qualquer, interessante para verificar dois sites hospedados no mesmo servidor e observar o carregamento afim de descobrir problemas se um sempre carregar mais rápido do que outro.

Posted in High Performance, Melhores práticas, Otimização, web2.0 ~ 1 Comment

Javascript Inline e External

{ February 10th, 2008 }

Autor: cmilfont

Scripts internos (Inline) ao HTML agilizam em grande parte a exibição porque diminuem o número de requisições HTTP.
Imagine que você tenha uma página com scripts separados:

<script … src=”script1.js”></script>
<script … src=”script2.js”></script>
<script … src=”script3.js”></script>

Nesse caso teremos 3 requisições além da página e sofreremos um aumento de até 50% no tempo de renderização. Isso porque apesar do tamanho dos arquivos serem o mesmo se fossem internos, as múltiplas requisições provocam um overhead.

Ao invés dessa abordagem, se os scripts fossem internos, existiria uma única requisição HTTP e o tempo de renderização seria mais rápido.

O problema na abordagem de scripts internos é que não nos beneficiamos do cache.

Combinando os scripts

Uma alternativa é combinar todos os scripts para forçar apenas uma requisição e se beneficiar do cache.

Aliando a minificação do código, você reduz consideravelmente o tamanho do download do script. Observe que frameworks como o Extjs usam essa técnica, existe um arquivo ext-all.js que combina todos os componentes.

Para páginas que combinam um grande número de componentes e sofrem de elevado “Page Views“, é crucial o cache desses elementos em um único arquivo se beneficiando de poucas requisições HTTP e do uso do cache.

O problema nessa abordagem é que existem regiões com elevado “Page Views” que usam poucos componentes e tem que baixar todo o arquivo de uma só vez.

Download sob demanda

O melhor dos dois mundos é usar a estratégia de “Post-Onload Download” para os casos onde não há necessidade de baixar um script externo com todos os componentes. Nesse caso usamos a estratégia de Script tag e baixamos apenas os módulos necessários a determinada região do sistema. O código do sistema será dividido em módulos.

var head = document.getElementsByTagName("head")[0];
var script = document.createElement('script');
script.id = 'ScriptOnDemand';
script.type = 'text/javascript';
script.src = url;
head.appendChild(script);

Lembrando que essa técnica provoca uma aumento não só do esforço no desenvolvimento (porque você terá que administrar as dependências entre os componentes manualmente) como do tempo de manutenção no código (por dividir os scripts em módulos apropriados).

Conclusão

Faça poucas requisições HTTP para uma mesma página. Diminua sempre o número de requisições unindo todos os scripts em um único arquivo.

Caso o arquivo seja grande para uma página, adote a estratégia de subir os arquivos sob demanda.

A recomendação da estratégia adotada vai depender da métrica de cada região do seus sitema e do custo de esforço na administração desse código.

Posted in High Performance, JavaScript, Melhores práticas, Web Development ~ 3 Comments