Cada caso � um caso. BEA investe milhoes de dolares no desenvolvimento do WLS, JBoss � gratuito. Fa�a um teste com WLS 7 com o JDK da BEA (JRockit) e vc vai ver uma diferen�a ainda maior.
J� ouvi falar que vcs estavam pesquisando mudan�a de WLS para JBoss e pode at� ser uma escolha v�lida j� que provavelmente ser� incorporada como implementa��o de referencia igual Tomcat. O bom do OS � que, se vc percebe que ele n�o gerencia muito bem o pool de beans, e vc tiver o tempo, pode melhorar isso ;-) Eu fiz uns tested destas uns anos atr�s com Orion (US$ 1500) e percebi que o JSP/Servlet engine deles era muito mais r�pido do que JServ, Tomcat, WLS e BAS (na �poca Tomcat ainda n�o era o JSP engine da BAS). A escolha de uma app server na minha opini�o n�o poderia ser feito simplismente na base de custo e performance, cada uma tem as suas vantagens e desvantagens. Para CETIP poderia ser importante que WLS 7 � 100% integrada com HP openview. Para outras pode ser importante fazer CMP que n�o mapea para uma tabla s� (use BAS) outrous acham nome muito importante e escolham IBM. De QQ forma acho um benchmark baseada em um componente t�o banal n�o muito v�lido. Seria interessante fazer um benchmark usando o JPetstore da IBATIS que deve rodar sem modifica��o nos dois. Assim vc pode tirar algumas conclus�es v�lidas sobre a performance. > Ol� pessoal, > > Eu trabalho na Cetip (Camara de compensa��o de titulo) no Rio de Janeiro. > > Estamos usando o WebLogic 6.1. > > Eu estou tentando convencer o pessoal a usar o JBoss pelo menos em > desenvolvimento. > > J� que n�o achei benchmarks JBoss/Weblogic, Eu comecei a fazer um : > > Um teste simples : > > Um EJB(SessionBean) que calcula um factorial. > Um programinha que simula x clientes chamando esse EJB. > > O teste demonstrou que o weblogic era 50% mais r�pido acima de 50 clientes. > > Achei estranho e tentei analisar o comportamento do JBoss para entender. > Pelo jeito ele n�o gerencia bem o seu pool de session bean e n�o consegue > executar muitos clientes em paralelo. > > Tentei verificar a confirgura��o do pool de session bean, mas est� tudo ok. > > Algu�m j� reparou isso ? > > Ser� que a minha configura��o est� ruim ? > > OBS : > Eu estou usando JBoss3.0.3 e Weblogic 6 SP 1 > com jdk 131 da sun. > > Olivier > JConcept/Cetip > > > > -----Mensagem original----- > De: [EMAIL PROTECTED] [mailto:sven@;cilix.com.br] > Enviada em: quarta-feira, 30 de outubro de 2002 09:31 > Para: [EMAIL PROTECTED] > Assunto: Re: RES: [enterprise-list] CMP ou BMP > > > > Isso foi feito de proposto. Um finder no EJB n�o deveria devolver muitos > > objetos pois impacta muito no performance (uso de memoria etc). LIKE > > tipicamente devolve muitos registros do DB e por isso foi deixado fora > da > > especifica��o. > > > > Sim, mas por isso que eu digo que as pessoas que fizeram a especifica��o > s�o > > autistas. > > Se essa preocupa��o realmente fosse v�lida, a JBossQL com seu LIKE > > paramatriz�vel n�o > > faria tanto sucesso. > > Dizer que JBoss faz sucesso por causa do LIKE � meio banal. JBoss faz > sucesso por ser bom e especialmente GRATUITO. Usando LIKE em queries e > retronando grandes quantidades de EJB em consultas faz que a > escalabilidade vai pro saco. Se vc acha que o 'expert group' que faz a > especifica��o EJB � um conjunto de autistas (vc sabe o que � uma > autista?), nada impede vc pagar US$ 0, preencher o formul�rio e fazer > parte do JCP e discutir por que vc acha que LIKE deveria fazer parte da > especifica��o. > > > CMR � bom e � ruim, como j� foi dito nesta discuss�o. O que pode ser > feito > > com CMR en EJB 2.0 j� fiz tamb�m com CMP 1.1. Em termos de modelagem n�o > � > > t�o complicado. > > > > Complicado n�o �. Mas tamb�m n�o � nada elegante. > > � t�o elegante quanto CMR. > > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: enterprise-list- > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: enterprise-list- > [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
