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.
Ficamos encantados quando lemos artigos ou ouvimos cientistas ou visionários falarem em evolução, criação, inovação e renovação. Após cada artigo lido ou palestra assistida, chegamos a conclusão: É isto que eu quero, é assim que vou trabalhar a partir de agora, minha vida vai mudar a partir deste momento.
O entusiasmo logo passa ao chegarmos em nosso trabalho ou em no ambiente social. Por que motivo isto ocorre? Fico me perguntando. E cheguei a uma conclusão. O entusiasmo só acaba por falta de perseverança, ele acaba sempre por querermos trilhar os caminhos já abertos ou pelo medo da mudança.
Após esta concepção, comecei a compreender melhor o por quê de alguns profissionais de TI terem tanto objeção a utilização de Software Livre. Mesmo com vários cases de sucesso amplamente divulgados, encontramos profissionais ainda resistentes à adoção de SL, justamente pelas mudanças a que ele está destinado a realizar.
O Software Livre traz profundas mudanças no modelo de negócio, implantado pelas grandes empresas de TI e adotados pelas demais. O modelo determinístico e proprietário ao qual nos adaptamos por achar que era o único e o ideal passa a ser questionado. As perguntas que pareciam óbvias e que não fazíamos, agora começamos a fazer.
Era comum uma empresa de solução em TI lhe dizer: "Para utilizar minha solução, sua empresa tem utilizar o software X+Y+Z e o hardware ABC, compatíveis com a tabela HCL do fabricante W. Só assim garanto meu SLA da solução".
Fazendo uma analogia a este modelo, imagine que você comprou um carro e o vendedor lhe disse que o carro só funciona com o combustível da distribuidora X utilizando o combustível 100% Y. Se todos concordássemos com este modelo, nunca presenciaríamos a invenção dos carros flex e não veríamos o biodisel ser utilizado.
Felizmente começamos a pensar diferente, saindo um pouco daquele paradigma proprietário e determinístico.
Pesando desta maneira, a empresa onde trabalho vem lentamente quebrando estes paradigmas. Não só pela adoção de solução em SL, mas também por entender este novo modelo de negócio advindo do SL.
Recentemente contratamos uma solução em JAVA para substituição da aplicação responsável pelo auto-atendimento das agências e posto de atendimento. Aproximadamente 20.000 terminais.
Como a solução é em JAVA, ela poderia rodar em qualquer plataforma operacional, SUN, IBM e x86. Porém, o modelo de negócio determinístico e proprietário dizia que para este tipo de aplicação, dada a sua criticidade, só poderia existir duas plataformas candidatas. SUN e IBM.
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.
[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.
[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.
[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.
[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.
[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.
[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.
[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?!?
[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.
[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.
[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!!!
[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.
[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.
[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.
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:
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).
[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.