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]
