veja abaixo...
Paulo Andre Antonialli wrote, On 6/12/2002 11:41:
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.
Bem, recomendo inicialmente colocar no m�nimo 128 MB, mas isso
_depende_ fortemente da utiliza��o e quantidade de clientes.
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.
Na realidade n�o � o cache e sim o pool de EJBs. Verifique a quantidade
criada nos arquivos JBOSS_HOME/server/default/conf/standardjboss.xml
Pois bem, algu�m saberia me apontar na dire��o de melhorar a performance
de "levantamento" deste container?
Existem v�rias maneiras, diga se usa EJBs (qual o tipo e quantos),
quantidade de prov�veis clientes, apenas o JBoss acessa o container ?
Pensei num modelo sob-demanda, ou seja, o Jboss carregaria somente os
beans que fossem pedido � ele.
Voc� pode customizar quais os servi�os que o JBoss inicia, se voc� n�o
precisa de MQ pode tirar, entre outros, contrua sua configura��o em
JBOSS_HOME/server/<sua configura��o>, copiando o "default" por exemplo,
veja no diret�rio deploy quais os servi�os que voc� n�o precisa.
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" .
Se voc� est� preocupado em deploy e inicializa��o � porque ir� fazer
constantemente, logo acho que seja uma m�quina de desenvolvimento e se
for este o caso _aumente a mem�ria ram_. Veja a quantidade de objetos
criados no pool no arquivo standardjboss.xml
Esse meu pensamento � correto? Caso seja, como resolver esse paradoxo? O
Jboss possui uma funcionalidade "read-ahead". O que seria exatamente
esta funcionalidade?
Neste caso voc� usa EntityBeans, a funcionalidade "read-ahead" faz com
que quando se realiza um findByXXXX, o container usa a estrat�gia de
"read-ahead" para ler mais objetos em um �nico findByXXX.
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?)
Isso depende da quantidade de dados, e se forem realmente necess�rios
coloc�-los no combo box, verifique se um filtro n�o pode ser aplicado.
Para grandes quantidades de dados veja o Value List Handler.
Muito obrigado e um grande abra�o � todos desta lista, o n�vel das
discuss�es aqui presentes realmente � excelente!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Claudio Miranda <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
