Discussion :

[jejeman]

Bonjour,

Je vous explique mon souci. J'ai écrit une application qui récupère des données sur un serveur via REST. C'est données sont renvoyées en JSON et ensuite "décortiqués" pour créer mes objets dans mon appli.
En une seule requête, je récupère jusqu'à 130 objets en format json.
Pour lire les données j'utilise un StringBuilder, voici mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
            BufferedReader bufReader = new BufferedReader(new InputStreamReader(response));
            String sLine;
            StringBuilder sb = new StringBuilder();
 
            while ((sLine = bufReader.readLine()) != null) {
                sb.append(sLine);
                sb.append(lineSep);
            }
            try {
                js = new JSONObject(sb.toString());
            } catch (JSONException ex) {
                Logger.getLogger(HttpConnection.class.getName()).log(Level.SEVERE, null, ex);
            }

Mon souci est que l'ensemble des données renvoyé représente environ 25Mo. sur mon PC ça marche bien, mais j'ai essayé sur une autre configuration et là Java me fait un "java heap space" sur le sb.append(), problème de mémoire apparemment.
Du coup j'ai essayé de découper mes requêtes en plusieurs, à la première requêtes je renvoie la liste en ID de touts mes objets et ensuite, pour chaque ID je récupère les data.
Le souci c'est que ça prend 10 minutes !!!!! (130 requêtes au lieu d'une seule !)
Alors que de tout récupérer d'un seul coup ça me prend 40 secondes....
Comment est-ce que je peux améliorer ça ?
Merci de votre aide.

[joel.drigo]

Salut,

Qu'entends-tu par "autre configuration". Autrement dit, quelle est la mémoire allouée au tas dans cette autre configuration (paramètre -Xmx dans la ligne de commande). Si découper le traitement en plusieurs sous-traitements peut consommer moins de mémoire, globalement ça en consommera autant : tu risques donc non seulement d'avoir une perte de performance due au découpage, mais également due au Garbage Collecting qui va forcément se déclencher pendant ton traitement. Si tu peux augmenter la taille du tas, autant le faire. Attention par ailleurs aux autres traitements de ton application, qui pourraient présenter des fuites de mémoire (que tu ne constaterais que sur cette autre configuration, pour diverses raisons : ça dépend de ce qui est fait dans l'application). Le traitement de ta requête peut également présenter des fuites (par exemple, je ne vois pas de close(), ni de try-with-resources pour ton BufferedReader...)

[jejeman]

Merci de ton retour.
Mon PC est une station de dev sous linux avec java 7. L'autre configuration est un PC sous windows 7 avec la jre java 8. (d'ailleurs sur plusieurs autre config j'ai le même souci)
en ce qui concerne les open et close des connexions et les try-catch, ils sont là, je ne les ai pas mis sur mon exemple pour ne pas alourdir...
Après des recherches ils semblerait qu'on puisse augmenter la mémoire de la JVM mais dans mon cas, je ne veux pas y toucher car je me vois mal expliquer à mes clients qu'ils doivent lancer l'application avec une paramètre spécial...
Je vais essayer de tester de tout lire en un seul coup sans faire de append, vu que c'est cela qui a l'air de poser problème...
Merci !

[joel.drigo]

Après des recherches ils semblerait qu'on puisse augmenter la mémoire de la JVM mais dans mon cas, je ne veux pas y toucher car je me vois mal expliquer à mes clients qu'ils doivent lancer l'application avec une paramètre spécial...

Bah, ce n'est pas un paramètre spécial : si ton application a besoin de X mémoire pour tourner, il faut lui allouer X mémoire. Maintenant, c'est sûr, il faut faire attention à ne pas gaspiller inutilement de la mémoire, et en particulier faire attention aux fuites. Ensuite, lorsque c'est possible, éviter de charger la mémoire et préférer des traitements de flux (en utilisant Jackson par exemple, ou GSon (com.google.gson.stream.JsonReader)).

[thelvin]

C'est vrai que 25Mo sous forme de JSON échangé entre deux ordinateurs, ça risque de prendre pas mal de place en mémoire une fois transformé en objets utilisables. De juste pas rentrer, en fait.

Du coup la question à se poser est, combien de temps restent-ils en mémoire et quand en sortent-ils. Si par le plus grand des hasards ils ne sont pas censés y rester mais, à la place, rejoindre une base de données ou un fichier ou un site web ou que sais-je, dans ce cas il vaudrait mieux les traiter un par un. Ou dix par dix, ce genre de choses.
Attention je ne dis pas de faire plusieurs REST. Je dis de traiter les données au fur et à mesure qu'on les lit dans la réponse.

[tchize_]

Mon souci est que l'ensemble des données renvoyé représente environ 25Mo.

En considérant que c'est de l'ASCII ou similaire, que les char java occupent 16 bits, que le StringBuilder a besoin de faire des ArrayCopy réguliers et augment sa taille par facteurs de 2, ce processus occupe un espace de travaille pouvant aller jusque 200M pour avoir au final un String à convertir en JSON.