Arquivos da categoria: Sem categoria

Injeção de Dependência: comparação de desempenho

No presente post procurar-se-á demonstrar uma comparação entre injeção de dependência de dois grandes Frameworks, o JSF e o Spring. Para efeito de comparação também foi testada uma versão do aplicativo web com JSF sem o uso de injeção de dependência.

No desenvolvimento Web, diferentemente do desenvolvimento de aplicativos para Desktop, os sistemas muitas vezes possuem dezenas de milhares de usuários simultaneamente, isso exige um grande desempenho das aplicações.

Sendo assim a verificação do desempenho de diferentes formas de implementações, utilizando JSF com e sem injeção de dependência, que é uma forma de IoC (Inversion of Control – Inversão de Controle), e Spring, é importante e aponta para possibilidades mais adequadas, considerando as diferenças de desempenho entre os frameworks citados.

Os sistemas serão submetidos a testes de stress e desempenho. Para realização desses testes foi utilizado a ferramenta JMeter, uma ferramenta que diante das crescentes necessidades por performance vem sendo muito utilizada. Apache JMeter pode ser usado para testar o desempenho tanto em recursos estáticos quanto dinâmicos (arquivos, Servlets, scripts Perl, Java Objects, Bases de Dados, Consultas SQL, servidores FTP e muito mais).

Para o presente trabalho foram realizados dois testes para cada sistema desenvolvido, primeiro com 1000 usuários e o segundo com 4000 usuários. Esses dois testes foram realizados da mesma maneira com os três sistemas desenvolvidos (Spring com IoC, JSF com e sem IoC). Foram realizados testes com o máximo de 4000 mil usuários pois, o sistema após esse número apresentava a exceção “java.lang.OutOfMemoryError: Java heap apace” tornando impossível a realização de testes com maior número de usuários.

Como pode ser visto logo abaixo, o JMeter permite entre outras características as seguintes:

Tempo da amostra – tempo de resposta da aplicação;

Desvio – dispersão dos valores em relação à média;

Porcentagem de erro – porcentagem de problemas nas respostas;

Vazão – o número de operações que o sistema é capaz de completar em um dado período de tempo;

Carga Máxima do servidor – uso do processador pelo servidor;

Memória Máxima do servidor – uso de memória pelo servidor.

Tabela 1: Comparativo de desempenho com 1000 threads

Item Spring JSF com IoC JSF sem IoC
Tempo da amostra 75ms 74ms 39ms
Desvio 49ms 40ms 19ms
% de erro 0 % 0% 0%
Vazão 19,8/seg 19,8/seg 19,8/seg
Carga Máx. servidor ~37% ~60% ~50%
Memória Máx. servidor ~75% ~100% ~98%

 

Tabela 2: Comparativo de desempenho com 4000 threads

Item Spring JSF com IoC JSF sem IoC
Tempo da amostra 41ms 39ms 39ms
Desvio 89ms 25ms 18ms
% de erro 0%  0% 0%
Vazão 18,1/seg 19,6/seg 19,8/seg
Carga Máx. servidor ~48% ~35% ~48%
Memória Máx. servidor 95% ~80% ~90%

Através dos dados obtidos com os testes é possível identificar onde cada abordagem de desenvolvimento obteve um melhor desempenho com respeito à performance. Na tabela 1 e 2, foram agrupados os principais quesitos com respeito ao desempenho da aplicação para que pudéssemos analisar de forma mais clara.
Tempo da Amostra – Com relação a tempo, que seria o tempo de resposta da aplicação, na tabela acima temos a média de cada um. Observamos que o JSF sem Injeção de Dependência obteve resultados um pouco melhores, sendo em média mais rápido.
A porcentagem de erro ou problemas ao acessar a aplicação foi de zero por cento em todas as abordagens apresentadas.
A Vazão não foi muito diferente entre um e outro ficando novamente o JSF sem IoC um pouco à frente dos demais, mas apenas no teste com 4000 usuários, sendo praticamente insignificante a diferença haja vista que a própria rede pode apresentar oscilações na transferência de dados.
Agora com relação ao servidor de aplicações Tomcat, a carga do sistema obteve resultados na faixa de 35% a 60%, entretanto, não somos capazes de inferir nada com relação, pois em todos os testes houve oscilações durante o intervalo observado, sendo, que o Spring conseguiu se manter mais estável. Com relação ao uso da memória também não houve muita diferença.
Os testes foram realizados com o grupo máximo de 4000 usuários devido a estouro de memória no sistema quando utilizado por um grupo maior de usuários, apresentando a seguinte exceção: “java.lang.OutOfMemoryError: Java heap apace”. Com o número de usuários máximo utilizado nos testes, embora tenha havido algumas diferenças nos resultados, os sistemas se comportaram bem, não gerando gargalos nem indisponibilidade. Podemos perceber diante disso que com a melhora cada vez maior das técnicas de desenvolvimento de Frameworks e linguagens de programação o nível de qualidade se mantém quase igual, claro havendo algumas metodologias e facilidades diferenciadas em cada um.

CONCLUSÃO

Com todas as metodologias e técnicas utilizadas atualmente no desenvolvimento de ferramentas para auxílio dos programadores de sistemas, e até mesmo a maior especialização e estudo por parte das pessoas envolvidas nesse processo de desenvolvimento, tornou-se possível, excluindo algumas especificidades, que os níveis dessas ferramentas, como já dito anteriormente, quanto a desempenho se tornem muito parecidas, não havendo uma diferença muito grande.

O presente trabalho mostrou exatamente que as funcionalidades básicas, como é o caso da injeção de dependência, já estão bem consolidadas na maior parte dos Frameworks, logo, salvo funcionalidade muito específica, que seja provida por apenas um Framework, qualquer um dos Frameworks demonstrados aqui seria muito importante para um sistema em desenvolvimento e não haveria grandes problemas por adotar um ou outro, notando apenas que a injeção de dependência é um padrão de projeto e como tal já foi provado por anos de experiência em desenvolvimento de software, que é a forma mais indicada para desenvolvimento de sistemas complexos por facilitar muito o trabalho, tendo sido utilizada uma versão sem injeção de dependência no trabalho apenas por questões comparativas (mesmo que fosse muito mais eficiente não seria indicada por muitos outros fatores).

 

Personalizando Select com JQuery

Muitas vezes nos deparamos com situações que exigem o uso da propriedade select em algum projeto web. As vezes o projeto exige dos programadores que o select seja mais elaborado ou diferenciado.
Nos padrões do HTML temos um select com poucas alternativas de customização, o que, em muitos casos não vem acalhar com as nossas reais necessidades de personalização.
Quando tudo esta difícil na web aparece o JQuery para resolver a nossa vida. O plugin Custom Select trás toda a flexibilidade para adaptarmos o nosso select da forma que for necessário.

Exemplo do select no código HTML:

<select name="dormitorios"  title="Exemplo:">
    <option value="1">1 exemplar</option>
    <option value="2">2 exemplar </option>
    <option value="3">3 exemplar </option>
    <option value="4">4 exemplar </option>
    <option value="5">5 exemplar </option>
</select>

Vamos para a configuração:

1 – Baixar a biblioteca principal do JQuery  jquery.tools.min.js

2 -Baixar o plugin jquery.customselect.js

3 – Chamar os arquivos js em seu html:

<script type="text/javascript" src="/path/to/jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="jquery.customselect.js"></script>

4 – Inserir em seu código HTML a função que executa o nosso plugin;

<script type="text/javascript">
$(document).ready(function(){
    $('#select').SelectCustomizer();
});
</script>

 

CSS do select

Propriedade 1 – _iconselect

Vai ser a primeira parte do nosso select, onde se localizarão configurações como: tamanho da fonte, tipo de fonte, background do campo, entre outros.

Esta propriedade _iconselect é um sufixo gerado pelo próprio plugin.

Ex: A sua configuração no CSS ficará assim:

select_iconselect {
...
}

Propriedade 2 – _options

Esta propriedade é responsável pela configuração da nossa caixa de itens, ou seja, propriedades como tamanho da caixa, barra de rolagem entre outras. A propriedade no código CSS ficará assim:

select_options {
...
}

 

Propriedade 3 – selectwrapper e selectfooter

Esta propriedade vai configurar todos os itens do nosso select em associação com outras propriedades.

Aqui vai alguns códigos que serão relacionados com essa propriedade para a personalização do nosso select no CSS:

.selectwrapper {…}
.selectwrapper .selectitems{...}
.selectwrapper .last{...}
.selectwrapper .selectitems span{...}
.selectwrapper .hoverclass {...}
.selectwrapper .selectedclass {…}

Também temos a propriedade selectfooter que como o próprio nome induz, faz referencia a configurações do nosso rodapé, da caixa de itens.
No código CSS ficará assim:

.selectfooter {…}

Abaixo a imagem de um select personalizado:

OBS: Lembrando que estas propriedades são geradas automaticamente pelo nosso plugin. Por isso não incluímos nem uma dessas classes ao nosso HTML, apenas a propriedade select em sua forma natural.