charge serveur

Bonjour,

Depuis peu, j'ai mis en place un système de génération de XML sur un serveur qui est soumis à une forte charge (des dizaines de milliers de XML générés par jour). Les XML générés font de l'ordre de la centaine de Ko. Est-il possible que le problème vienne de JDOM ? Quelqu'un a-t-il déjà eu un problème similaire ? Est-ce que je peux régler ce problème en utilisant par exemple le DOM inclus dans la bibliothèque standard ?

En fait, en y réflechissant, c'est clairement la source du problème. Les XML étant très volumineux et très nombreux, les serveurs génèrent une pléthore d'objets (Element, Attribut, String...) qui encombrent le heap space, ce qui finit par faire tomber le serveur.

Par contre, je ne vois pas quelle solution apporter, à part générer le XML par un moyen unsafe, genre écrire les balises. Quelqu'un connait une alternative ?

... Il faudrait aussi nous dire quel problème tu as.

Sinon, pour information, 80 000 par jour par exemple, ça fait moins d'un par seconde. Je n'appelle pas ça une forte charge. J'appelle ça "quelque chose qu'il fait tout le temps et qui n'est pas du tout exceptionnel."

Citation:

---

Envoyé par Traroth2

Par contre, je ne vois pas quelle solution apporter, à part générer le XML par un moyen unsafe, genre écrire les balises. Quelqu'un connait une alternative ?

---

Une approche SAX est également consommatrice de ressource et mémoire. Mais beaucoup moins que DOM.

S'il y a une fuite de mémoire, je pense pas qu'elle vienne de JDom.
Tu dois garder une référence à des objets qui empeche le Garbage Collector de libérer la mémoire.
Un HeapDump te permettrait de voir le nombre d'instances par objets, après faut faire le tri :aie:.
Pour en avoir un automatiquement en cas de crash ajoute l'option java :

Code:

---

-XX:+HeapDumpOnOutOfMemoryError

---

Il y a un bon article pour analyser la mémoire java :
http://blog.xebia.fr/2008/11/27/anal...oire-dune-jvm/

Si, je pense que c'est bien là le problème.
D'après la doc Caucho (on fonctionne sur un serveur Resin), un fail over du serveur se produit quand le garbage collector réussit à récupérer moins de 2% de la mémoire en un seul passage alors que celle-ci est saturée à 98%. Ça aurait tendance à se produire quand on instancie un grand nombre d'objets. Vu la volumétrie, c'est à dire des dizaines de milliers de XML par jour, contenant chacun des milliers de nodes, ça fait un sacré paquet d'objets Java, justement.

Je vais réimplémenter mon système en utilisant StAX, qui a justement été créé pour résoudre ce type de problème.

Une fois le arbre Jdom serializé de la mémoire vers le disque, tu n'as plus de raison de conserver des références à ce dernier.
Il faut bien vérifier ce point qui n'est pas propre à JDom, mais à l'utilisation de JDom par ton appli.

Le garbage collector va libérer régulièrement la mémoire en scannant les ressources qui n'ont plus de références. Le garbage collector est très efficaces pour recycler des milliers d'objets lorsqu'ils ont une "vie" courte en mémoire.

Des xml de ~100ko, c'est idéal pour une approche Dom, Sax est a utilisé plutôt quand on cherche un traitement évènementiel sur des XML bien plus gros.

Attention, je parle bien de StAX (Streaming API for XML), pour générer du XML et non SAX pour le parser. Je me sens bête de ne pas y avoir pensé tout de suite, en fait.

Je pense que le souci, c'est que là, on en est à des millions d'objets instanciés, en fait.
100 ko par fichier xml, chez nous, c'est une petite moyenne. Mais on a bien plus lourd, et sur des dizaines de milliers de connexions par jour.

Le constat, c'est que quand on utilise l'application sur le serveur de test, tout se passe bien, même sur la durée. Ce n'est donc pas à proprement parler une fuite mémoire.
Par contre, quand on passe en production (notre site a pas mal de trafic), ça pète en quelques minutes.

Oui, ben stax ça reste une approche évènementiel mais en "pull" en non en push comme sax. Et c'est plus simple à appréhender, je te l'accorde.

Mais là, tu laisse tomber ton problème initial pour aller essayer une autre approche en espérant que ça résolve tout.
Je pense vraiment que JDom en lui même ne comporte pas fuite de mémoire, il est quand même extrêmement utilisé et répandu en entreprise.

Il est en tout les cas bien plus testé que stax qui date de 2006.
Et avant de prendre des mesures aussi drastiques, je conseillerais de vraiment fouiller dans la mémoire et voir ce qui est la cause de ton OutOfMemoryError.

Citation:

---

Envoyé par Traroth2

Attention, je parle bien de StAX (Streaming API for XML), pour générer du XML et non SAX pour le parser.

---

Juste pour info, entre SAX et StAX il n'y a qu'une différence de style (push or pull.) Pas de capacités ni d'applications : les deux permettent de lire ou écrire du XML en streaming.

C'est juste pour préciser. L'un ou l'autre c'est très bien.

Ah bon, SAX permet de générer du XML, maintenant ? Je l'ignorais. Selon quel principe ?

Oui, je le savais pas non plus à la base mais thelvin l'avait mentionné il y a quelques temps :
http://www.javazoom.net/services/new...eneration.html
Cf l'exemple 5.

Je ne vois pas en quoi c'est si difficile à imaginer d'ailleurs. Le code pour le faire en Java est peu connu d'accord, mais le principe marche clairement dans les deux sens.

Cette classe XMLSerializer a l'air d'être spécifique à Xerces. En tout cas, je n'ai pas l'impression qu'elle fasse partie de SAX, tel que décrit sur le site officiel :

http://www.saxproject.org/

Pour s'en convaincre, il suffit de regarder la Javadoc officielle de SAX :

http://www.saxproject.org/apidoc/index.html

En tout cas, c'est effectivement une possibilité intéressante.

Citation:

---

Envoyé par Traroth2

Cette classe XMLSerializer a l'air d'être spécifique à Xerces. En tout cas, je n'ai pas l'impression qu'elle fasse partie de SAX, tel que décrit sur le site officiel :

http://www.saxproject.org/

---

Pour l'amour du ciel, c'est une recommandation d'API qui définit un type d'objet qui a des méthodes startDocument(), startElement(), characters(), etc.
Que diable faut-il de plus ? J'insisterai pas.