Teste de estresse entre software livre e soluções proprietárias

Descrevo neste artigo um teste de estresse que realizamos em nossa empresa envolvendo solução em software livre em x86 64 bit (Debian, Postgree e JBoss) versus SUN (Solaris, Oracle e Sun Java System) e IBM (ZOs, DB2 e Websphere). O artigo ficou um pouco longo, mas vale a pena.

[ Hits: 65.729 ]

Por: Jaca em 24/08/2007


Características do teste



Para definição de qual plataforma implementaríamos a nova solução de auto-atendimento, resolvemos fazer um teste de estresse da solução nas diferentes plataformas, seguindo alguns critérios. Além das duas plataformas candidatas, resolvemos trilhar um novo caminho, incluindo a plataforma x86 com solução 100% em Software Livre.

Os critérios para realização do teste, a plataforma deveria apresentar disponibilidade de 995%, tempo médio de transação inferior a 1,5 segundo e suportar 700 a 750 TPS (transação por segundo), numa massa de teste de 1 milhão de transações.

Estabelecidos os critérios, definimos a arquitetura, conforme a figura 1. Uma máquina utilizando o JMETER simula a carga transacional, a ser submetida a solução, o middleware é composto pela solução de auto-atendimento com as diferentes plataformas, e por fim um simulador de host que recebe e retorna as respostas transacionais.

Neste teste o JMETER e o simulador de Host possui a mesma configuração de hardware para as três plataformas, x86 64 bit, SUN e IBM.



Página anterior     Próxima página

Páginas do artigo
   1. Quebrando paradigmas
   2. Características do teste
   3. Configuração de cada plataforma operacional
   4. Resultados obtidos
   5. Conclusão
Outros artigos deste autor

Instalando placa wireless Intel 3945ABG no Debian

Instalando leitor de finger do T60 no Debian Etch

Internet no Linux através de celular HTC TYTN II

Leitura recomendada

Conexão dial-up no Gnome usando o network-admin

Assistindo TV usando a placa VideoHighway Xtreme (ou outra baseada no bttv)

Servidor VPN PPTP com autenticação de usuários no Active Directory

Chakra GNU/Linux

Fontes com filtros LCD no Arch Linux

  
Comentários
[1] Comentário enviado por fabio em 24/08/2007 - 04:51h

Bacana sua iniciativa de compartilhamento desse case. Uma das mensagens "best-sellers" que recebo no fale conosco aqui do site é de gente pedindo informação sobre comparações entre Windows x Linux e histórias de sucesso na adoção de SL.

Um abraço.

[2] Comentário enviado por julianopiedade em 24/08/2007 - 08:36h

Parabéns pela qualidade do artigo.

Frequentemente sou questionado sobre a viabilidade de implantação de Softwares Livres e dificilmente encontramos cases como este, de grande porte, relatados nas comunidades Linux.

Obrigado pelo compartilhamento da experiência.

[3] Comentário enviado por komigachi em 24/08/2007 - 08:37h

Meu amigo sua analise foi especifica,analistica,praguimatica e eloquente(q diabo tou falando),parabens por passar essa linda experiencia com agente,suas primeiras palavras de introdução desse artigo foi a melhor forma de explicar a nossa facinação por sistemas OS.

[4] Comentário enviado por juninho (RH.com) em 24/08/2007 - 09:02h

Cara, que empresa é esta que você trabalha, que estrutura forte ela tem hein, poucos aqui já devem ter visto falar em tão forte estrutura de Hardware e Software ( como eu ).
Mas como é ótimo ver cada vez mais gente mostrando como o Software Livre é forte, principalmente em tamanha aplicação.

Parabéns, seu artigo é maravilhoso.

[5] Comentário enviado por rwpatriota em 24/08/2007 - 10:06h

Boa, Jair! O artigo ficou muito bem elaborado.

Acho muito importante a divulgação destes testes para a comunidade. Não só pela comprovação da qualidade técnica da solução, mas principalmente pela questão dos paradigmas.

Mais uma vez parabéns.

[6] Comentário enviado por White_Tiger em 24/08/2007 - 10:48h

Muito bom o artigo. fiquei curioso em saber qual a sua empresa.

[7] Comentário enviado por wesleyfp em 24/08/2007 - 10:57h

Muito Bom Jair, mais uma vez provamos que o software livre está cada vez mais forte dentro da nossa empresa! parabéns!

[8] Comentário enviado por engos em 24/08/2007 - 12:45h

Primeira vez que digo isso em um artigo aqui no VOL, mas não há outra palavra: IMPRESSIONANTE!

Nunca havia visto um stress test elaborado dessa forma e com um ambiente desse naipe.

O artigo está bem simples de se compreender e completo com o que interessa sem rodeios, sem dúvidas o melhor que já li por aqui (e olha que já li os meus também) até o momento.

Parabéns!

[9] Comentário enviado por scsidney em 24/08/2007 - 13:09h

Primeiro Parabéns,

Artigo de ótima qualidade, bem elaborado e colocando passo-a-passo todo o teste executado inclusive com documentos.

É por isso que acredito no SL, por existirem pessoas como você Jair, com coragem e boa vontade de trabalhar.

Cito, a postar tal artigo em outros fóruns com forma de agregar valores ao trabalhos feitos com SL, e dar estimulo a quem está indeciso.

Novamente, parabéns!

[10] Comentário enviado por velosologan em 24/08/2007 - 14:04h

Parabens Jair.

Mando muito bem. A descrição dos testes relatada no artigo foi bastante clara e objetiva.

É por isso que digo sempre (frase adptada de John of Salisbury): Para ver mais longe é preciso sentar no ombro de pinguins gigantes.

Sds

[11] Comentário enviado por adrianoturbo em 24/08/2007 - 14:32h

Uma coisa é certa a partir de agora você não terá nenhum tipo de estress entre soluções Livre e soluções proprietárias,pois já está vacinado contra a indecisão que muitas empresas têm na hora de montar uma estrutura ERP que atenda os anseios da mesma.Ficou evidente em seu artigo que as soluções livres tem um custo benifício considerável,que nos leva a chegar a conclusão que é viável a utilização destas ferramentas.
De qualquer forma parabéns pelo excelente artigo que com certeza contribuirá e muito para o enriquecimento de conhecimento de nossa comunidade.
E viva o LINUX.

Abraço!

[12] Comentário enviado por fabiobarby em 24/08/2007 - 15:12h

Ótima referência este seu trabalho.

Parabéns!

[13] Comentário enviado por f_Candido em 24/08/2007 - 18:30h

Muito bom. Parabéns.
Vlws por compartilhar.

[14] Comentário enviado por an_drade em 25/08/2007 - 12:02h

Excelente artigo. Gostaria de comentar primeiro o formato do mesmo, com introdução, métodos, resultados e discussão. E acima de tudo, rápido e simples de entender, como deve ser um artigo no VOL.

Acho q existem outras resistências mais p/ adoção do SL ainda. A cultura de instrutores ainda é pautada em soluções clássicas. Veja, por exemplo, o conteúdo da maioria dos cursos técnicos e tecnológicos de informática e de sistemas da informação. São pautados em soluções clássicas e pagas.

Sinto muito isso na pele. Sou prof. de um curso técnico em informáica em um CEFET recém-criado. Somos 5 profs., dos quais apenas eu sou partícipe da causa SL. Vivo tentanto mudar nossos conteúdos p/ Java ou Python, Llinux, Apache, MySQL, Postgree, etc, etc, mas sinto uma ENORME resistência.

Será que meus alunos ao saírem para o mercado, vão prefirir plataformas livres ou plataformas pagas, visto que apenas 1/5 dos professores deles apoiam e utilizam efetivamente SL?!?

Fica a reflexão.

E mais uma vez, parabéns pelo artigo.

[15] Comentário enviado por _simmons_ em 25/08/2007 - 19:26h

Parabéns pelo artigo Jair. É muito bom ver testes desse porte aqui no VOL.

Na empresa onde trabalho usamos uma estrutura parecida com a que você demonstrou, a diferença é que utilizamos cluster de JBoss/Mysql e para o balanceamento de carga usamos OpenBSD's.

Obrigado pela contribuição!

[]'s

André Michi

[16] Comentário enviado por _simmons_ em 25/08/2007 - 19:26h

Parabéns pelo artigo Jair. É muito bom ver testes desse porte aqui no VOL.

Na empresa onde trabalho usamos uma estrutura parecida com a que você demonstrou, a diferença é que utilizamos cluster de JBoss/Mysql e para o balanceamento de carga usamos OpenBSD's.

Obrigado pela contribuição!

[]'s

André Michi

[17] Comentário enviado por jaca69 em 25/08/2007 - 22:42h

A Todos,

Desde de já, agradeço a vocês pelo colaboração.
Espero ter contribuido e o mais importante, espero ter criando alguma dúvida aos mais cépticos, que acham que a melhor solução em TI é aquela que se paga. E muito!!!

[18] Comentário enviado por malanga em 26/08/2007 - 13:22h

Muito bom mesmo,

provando novamente que LINUX nao 'e somente pela econimia...

parabens, precisamos mesmo de material que comprove e aprove a qualidade dos sistemas SL.

Abracos.

[19] Comentário enviado por ewaldoquint em 27/08/2007 - 16:01h

Ficamos apenas curiosos para saber qual empresa que tem esse poder tecnologico em mãos para realizar o teste, sé for possível divulgar.

Abração e Parabéns!

[20] Comentário enviado por Legendario em 27/08/2007 - 18:30h

Muito bom! Parabéns pela iniciativa de compartilhar um case desse!

[21] Comentário enviado por felipph em 28/08/2007 - 08:32h

Exelente esse artigo! Parabéns!

[22] Comentário enviado por fike em 28/08/2007 - 10:13h

Parabéns.

É preciso muito coragem para executar um teste desse tipo e porte. O ponto chave não é somente economia e ser software livre, é ter a possibilidade de reter o conhecimento para equipe da empresa/instituição possa evoluir a solução ou mesmo só manter.

[23] Comentário enviado por georgebessa em 28/08/2007 - 17:53h

Parabéns Jair ! O artigo está excelente! Realmente, esses testes foram muito bem feitos, com ótimos resultados. E a conclusão é muito esclarecedora.
Foi o melhor artigo que já li, aqui no VOL.

[24] Comentário enviado por hiroyuki em 28/08/2007 - 18:53h

Jair, estou chorando de emoção haha Excelente o artigo! Meus parabéns!
Tenho que mostrar esse artigo pro meu chefe haha.

Grande abraço!!!

[25] Comentário enviado por FlavioMachado em 28/08/2007 - 20:34h

Eu sei qual é a empresa ... Mas não conto :) Não sei se está autorizado. (sim, trabalho na mesma empresa).

Eu até tenho um dedinho nesta história quando discuti com a pessoa da mesma equipe que eu e que participou junto com o Jair deste teste: uma das minhas sugestões foi justamente colocar o fator custo na avaliação, pois como Administrador, custo / benefício é a medida mais importante, não a excelência técnica a qualquer preço nem apenas baixo custo a partir de sacrifícios. Com certeza a mesma idéia deve ter sido discutida pelo Jair e, com duas pessoas favoráveis, o processo correu como deve ser toda análise.

Até eu me espantei com a diferença de preços, é algo absurdo demais até para imaginar. Mas eu vi o documento, é isso mesmo, 1% do custo com o mesmo ou maior benefício se considerarmos a redundância e escalabilidade quase linear.

Como não estive diretamente envolvido, parabenizo o Jair e os demais que participaram do teste por ter a coragem de botar a cara na janela para defender o melhor para a empresa sem preconceitos de software proprietário ou livre. Muito bom.

[26] Comentário enviado por fabio em 06/09/2007 - 08:52h

Repassando :)

De: Isis <isismsilva@xxx>
Assunto: Excelente Artigo

Senhores,

Parabéns pelo excelente artigo contido neste site. Me refiro ao teste de estresse entre solução livre e proprietária de Jair Silva.

Parabéns.

Isis

[27] Comentário enviado por TheGodZillA em 12/09/2007 - 13:09h

Parabéns pelo artigo...

Pena não ter mais detalhes sobre a configuração de jvm, threads e patchs, mas eu ainda acredito nos benchmarks que são publicados no www.spec.org .

Creio que o baixo desempenho da Sun F15k deva-se ao não cumprimento das recomendação que se encontram nos manuais de configuração.

Com os poucos detalhes fornecidos pelo autor identifiquei que o AS8.2 possuia 1 instância contra 3 jboss sendo balanceadas, considerado a configuração padrão do AS8.2 somente 200 threads estavam sendo executadas tirando as do GC supondo [ParNew] -36.

Recomendo que voce afira melhor as configurações utilizadas para que seu benchmark seja real.

Outros pontos de recomendações freqüentes inferem no tuning do Solaris e na utilização do SJSWS para o conteúdo estático e loadbalance da aplicação, consulte os manuais de tuning dos produtos envolvidos.

Abraço...

[28] Comentário enviado por jaca69 em 13/09/2007 - 00:42h

...

[29] Comentário enviado por TheGodZillA em 13/09/2007 - 13:12h

Jair,

Voce pode tomar como base o SPECjbb2000 feitos com PowerEdge 6850 e F15k para o seu benchmark.

Vou deixar os detalhes e ir direto ao ponto:

F15K -> 72 cores
SPECjbb2000 (from 74 to 148) 433.166 ops/s
SPECjbb2000 (from 74 to 148) 404.472 ops/s
F15K -> 104 cores
SPECjbb2000 (from 112 to 224) 602.270 ops/s

DELL -> 4 cores
SPECjbb2000 (from 8 to 16) 126.967 ops/s
SPECjbb2000 (from 8 to 16) 156.064 ops/s
SPECjbb2000 (from 7 to 14) 108.492 ops/s

Sua configuração possui 36 cores não seria injusto atribuir (sum) / 2 dos dois resultados obtidos na configuração de 72 cores.

F15K -> 36 cores
"Média" (from 37 to 74) 209.409 ops/s

Veja que os numeros entre parênteses representam o (warehouse) obtido no benchmark, ao meu ver representa a escalabilidade alcançada.

Como disse deixei os detalhes de fora, atento:
- Sun usou JDK 1.4 por outro lado a Dell usou BEA WebLogic JRockit 1.5.0.
- Data do benchmark F15K foram feitos em 2002 a Dell foi em 2005.

Existem manuais e recomendações da Sun que vão ajudar voce a obter máxima performance do seu ambiente, dentre eles posso citar:

819-2561, Performance Tuning Guide
819-2560, Deployment Planning Guide
819-2555, HighAvailability Administration Guide
819-6516, Performance Tuning, Sizing, and Scaling Guide

Outro caminho é acionar o suporte para resolução do problema da baixa performance.


Benchmarks configurações variadas da Dell PowerEdge 6850:

http://www.spec.org/osg/jbb2000/results/res2005q2/jbb2000-20050506-00341.html
http://www.spec.org/osg/jbb2000/results/res2005q2/jbb2000-20050315-00319.html
http://www.spec.org/osg/jbb2000/results/res2005q2/jbb2000-20050315-00321.html


Benchmarks antigos de configurações variadas da F15K:

http://www.spec.org/osg/jbb2000/results/res2002q2/jbb2000-20020507-00129.html
http://www.spec.org/osg/jbb2000/results/res2002q2/jbb2000-20020507-00130.html
http://www.spec.org/osg/jbb2000/results/res2002q1/jbb2000-20020207-00107.html


Documentação do jbb2000

http://www.spec.org/jbb2000/docs/userguide.html

1.2 General Concepts

A warehouse is a unit of stored data. It contains roughly 25MB of data stored in many objects in many Btrees. A thread represents a terminal user within a warehouse. There is a one-to-one mapping between warehouses and threads, plus a few threads for SPECjbb2000 main and various JVM functions. As the number of warehouses increases during the full benchmark run, so does the number of threads.

A "point" represents a two-minute measurement at a given number of warehouses. A full benchmark run consists of a sequence of measurement points with an increasing number of warehouses (and thus an increasing number of threads).

[30] Comentário enviado por structsockaddr em 13/09/2007 - 21:39h

....

[31] Comentário enviado por jaca69 em 14/09/2007 - 00:29h

...

[32] Comentário enviado por structsockaddr em 14/09/2007 - 03:34h

...

[33] Comentário enviado por TheGodZillA em 14/09/2007 - 08:16h

Bom dia a todos,

Caro Jair,

Não sei do que voce esta falando sobre eu ter participado do processo não lhe conheço e muito menos o "structsockaddr".

Que pena não ter alcançado o máximo da F15K pelo spec.org voce tem idéia da capacidade dessa maquina. Alias o spec.org não mente é padrão de referencia mundial, existem empresas que só compram HW baseados nos resultados obtidos no spec.org.

Esta sendo lamentável ler isso no fórum, é lamentável saber que no futuro isso ira permanecer para que nossos colegas leiam e tirem conclusões erradas sobre a F15k, tenho uma estrutura semelhante aqui no Sul e 700 tps é café com leite pra essa maquina.

Trocar insultos ou acusações não é o melhor caminho, muita calma nessa hora, tive casos em que o sistema só desempenhou bem quando foram feitas mudanças no código java "principalmente em static, singletons" a Sun tem arquitetura diferente então threads, LWP e scheduler trabalham diferente do x86, veja que existem varias técnicas para detectar problemas de desempenho o primeiro passo é o "kill -3" depois voce pode ler o doc intitulado " jdk50_ts_guide.pdf e memorymanagement_whitepaper.pdf " ambos fornecem procedimentos para detecção de lock e resolver baixa performance.

Sobre o SL acho que tenho os discos do minix aqui na gaveta, o jboss é outra historia esse tem problemas diversos com threads, classloader e crosscontext. Esses problemas somados a uma grande coleção de pacotes pode proporcionar um ambiente muito instável, resumindo o dia em que o jboss tiver um spec.org publicado eu re-acredito nele.

[34] Comentário enviado por jaca69 em 14/09/2007 - 09:07h

...

[35] Comentário enviado por structsockaddr em 14/09/2007 - 10:31h

....

[36] Comentário enviado por structsockaddr em 14/09/2007 - 10:46h

Chega de discussao.

[37] Comentário enviado por albfneto em 08/10/2008 - 18:51h

O artigo é excelente, um dos melhores que ví aqui no VOL.

[38] Comentário enviado por felipe.ds.magno em 17/03/2011 - 19:05h

Ótimo artigo! Parabéns!!!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts