1- sempre diga a vers�o com que est� trabalhando : SO, vers�o jboss 2- que tipo de beans est� usando
Paulo Andre Antonialli wrote: > Bom dia amigos. > > Desenvolvemos uma aplica��o para rodar no cliente (utilizando EJB e > J2EE). O cliente, inicialmente, havia dito que seus computadores teriam > 256 de ram. Pois bem, desenvolvemos uma aplica��o piloto (com > funcionalidades reduzidas) e, para nossa surpresa, o pc do cliente > possu�a apenas 64 de ram, ou seja, a performance de nossa aplica��o n�o > foi t�o aceit�vel assim. > realmente 64 para um servidor com jboss � inaceit�vel. > O grande problema foi o seguinte: Instalamos tudo e, na hora que fomos > dar a carga nos beans, o Jboss levou MUITO tempo (mais especificamente, > quase 5 mins) para levantar. Acredito que ele demorou muito porque > estava fazendo o cache dos beans. Disse "acredito" porque n�o fui eu > quem instalou a aplica��o. como assim cache dos beans, vcs usam CMP?, mas no start-up do servidor n�o � realizado nenhum cache de beans, s� na hora em que estes s�o utilizados. > > Pois bem, algu�m saberia me apontar na dire��o de melhorar a performance > de "levantamento" deste container? > + m�moria + CPU > Pensei num modelo sob-demanda, ou seja, o Jboss carregaria somente os > beans que fossem pedido � ele. � assim que funciona por default, > > Vejo que isso poderia diminuir o n�mero de beans que seriam carregados > pelo container na hora em que ele estiver sendo levantado e, > conseq�entemente, melhoraria a performance em tempo de deployment. Por > outro lado, acho que a performance do aplicativo em tempo de execu��o > cairia porque os beans n�o estariam "cacheados" . > > Esse meu pensamento � correto? Caso seja, como resolver esse paradoxo? O > Jboss possui uma funcionalidade "read-ahead". O que seria exatamente > esta funcionalidade? > o read-ahead executa menos sql, quando vc manda ler um bean de uma cole��o (o jboss s� tinha carregado as pk's), por default o jboss gera um sql para cada bean. O read-ahead faz "ler-adiante", fazendo com que na leitura de um bean os pr�ximos 'n' (n = tamanho da p�gina) sejam j� lidos. o read-ahead pode ser por 'on-find' ou por 'on-load', quer dizer, quando localiza os bean (no m�todo finder) ou quando carrega os dados de um bean (on-load). dependendo do tipo de aplica��o vc escolhe entre estas op��es. por exemplo, se vc vai apresentar apenas 10 por p�gina, a melhor op��o seria on-load, com tamanho de p�gina =10. > J� estou utilizando alguns patterns (session fa�ade, service locator, > Business delegate e value objects) e tamb�m struts. Li uma vez na lista > que, quando devemos carregar uma combo com uma quantidade grande de > valores, que o Data Access Object Pattern (DAO) seria mais indicado do > que fazer a carga da combo na entitiy. Minha aplica��o n�o foi > desenvolvida seguindo este pattern... o refactoring da minha aplica��o > para a "adapta��o" do DAO seria muito custosa? (dif�cil?demorada?) > o problema � que ao ler uma qtde muito grandes de entities, o jboss gera um sql para cada relacionamento (CMR) acessado. quer dizer, em um relat�rio de 1.000.000 de um bean com 4 entities relacionados, seriam gerados 4.000.000 + 1 de sql's, ou seja, invi�vel. Falei com o dain sundstorm, o cara respons�vel pelojboss-cmp, ele falou que no jboss 4, haver� read-ahead de relacionamentos, o que tornaria bem mais vi�vel a utiliza��o de CMP em 100% de uma aplica��o. > > > Muito obrigado e um grande abra�o � todos desta lista, o n�vel das > discuss�es aqui presentes realmente � excelente! > -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959 | | SICREDI Servi�os | | Porto Alegre - Brasil | |xxxxxxxxxxxxxxxxxxxxxxxxxx| --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
