Merci pour toutes ces reponses,
en faites au niveau de la m�moire, des threads, et de la mont�e en charges j'etais au courrant,
je me demandais juste si il y avait d'autre points bloquant.
Par exemple sur une architecture 32 bit, avec 2Go de memoire si je cree (j'ai pas fait le calcul par rapport a la taille d'un objet)
plusieurs millions de tout petits objets, est ce que les perfs s'ecroule a un moment ? ou est ce que il y a une limite ? est ce que la JVM index qq part tout ses objets et a fix� une limite ? ou des truc du genre ?
Pourquoi cette question ? car sur Jalios (ex: java-channel) on travail avec un graph d'objet en memoire, qui peut potentiellement etre tres tres gros, nous disons a nos client que la seul limite est la taille de la m�moire (plus d'autre details), maintenant est ce qu'il la JVM de Sun bloque autre part ? Sacant qu'on a pas de pb de Thread ou autre ...
Merci,
@+,
Jp
At 21:11 20/06/2002 +0200, you wrote:
Avec une JVM 32 bit, tu auras un peu moins
de 4Go utiles dispo pour tes objets.
Un tuning cot� GC est souvent n�cessaire
et l'URL de Laurent est une tr�s bonne source
d'info sur le sujet. Il faut souvent trouver
un compromis entre nombre de d�clenchements
et dur�e de ces pauses. plus la JVM est r�cente,
meilleur est le GC et meilleurs sont les
comportements par d�faut (sans tuning).
Cot� programmation, deux r�gles d'or:
- ne jamais faire d'appel � System.gc()
- ne pas utiliser de finalizers.
Une JVM 64 bits (dispo � partir de 1.4 chez Sun)
permet un adressage de m�moire sur 64 bits.
Son utilisation n'est justifi�e (� mon avis) que
pour quelques rares applis et elle n'est en tout
cas pas utilis� avec des serveurs d'appli J2EE
dont la plupart utilisent moins de 2Go.
Cot� threads, la limite est souvent celle
de l'OS. Il est d'ailleurs int�ressant de pouvoir
changer de biblioth�que de threads (de mani�re
de faire le mapping entre thread Java et thread
"natif").
Sinon, rassures moi, "gros syst�me" != "mainframe" ? ;-)
Cdlt,
Alexis
Laurent Nel wrote:
Bonjour,
Pour une appli serveur, il est tr�s utile de conna�tre finement le cycle de vie de ses objets, afin de param�trer pr�cisemment les tailles des zones m�moire g�r�es par le GC (NewGeneration, survivor spaces, etc ...). Cela peut donner des diff�rences spectaculaires en mati�re de performances. Infos: http://java.sun.com/docs/hotspot/gc/
Laurent NEL
www.leuville.com <http://www.leuville.com> / Conseil - Ing�nierie - Formation
Java - J2EE - UML
mailing-list J2EE francophone: http://www.leuville.com/entry_servlet?screen=j2eelist
----- Original Message -----
*From:* Jean-Philippe Encausse <mailto:[EMAIL PROTECTED]>
*To:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
*Sent:* Thursday, June 20, 2002 11:32 AM
*Subject:* Performances Java
Salut,
est ce que vous connaissez les limites "en gros" de la JVM ?
est ce qu'il y a une limite au niveau du nombre d'objet cree ou des
trucs du genre ?
ou est ce que c'est lineaire, tant qu'on a de la memoire on peut
creer des objets ?
est ce qu'il y a d'autres limites auxquelles il faut faire attention
lorsqu'on fait une appli
serveur pour un gros systeme ?
Merci,
@+
Jean-Philippe Encausse
[EMAIL PROTECTED] - http://www.encausse.net
ICQ: 109796741 - AOL: NextOne6666 - Mob: 06.63.47.93.13
Do it Once, Use it Twice ~ Do it Twice, Generalize It
