Discussion :

[livenono]

Bonjour

En regardant un problème de performance, on m'indique, afin d'expliquer la lenteur d'une JVM faisait du multihread face à plusieurs JVMs faisant du monothread, la chose suivante:

the tcp stack is the limiting factor in the big case
so more jvms gets you more kernel access

Autrement dit, que 4 JVMs n'ayant qu'un thread tournent chacune plus vite en moyenne qu'une seule JVM avec 4 threads serait expliquée par des limitations d'accès à la couche TCP pour chaque JVM => 4 JVM permettant dès lors d'avoir "plus d'accès". Le tout sur un quadcore 64bits tournant sous ubuntu 10.04.

Avez vous déjà entendu parler d'une telle chose ? Cela vous semble t il plausible ? Est ce contournable ?

merci d'avance

cordialement
nono

[tchize_]

il y a peu de chance. D'abord parce que sous certains os, aucune distinction n'est faite etre plusieurs process et plusieurs thread (les thread sont vus comme des process distinct, mais partageant leur zone mémoire). Aller prétendre que le stack tcp est la casue des problème de performance, sans une analyse détaillée du programme, c'est assez difficile. Si votre problème se situe au niveau des perfs tcp/ip, c'est le language qui est à changer, pour avoir un accès plus direct à la couche

De plus, la synchronisation, lorsqu'elle sera nécessaire, sera plus compliquée et lente à atteindre avec plusieurs jvms.

[livenono]

merci pour cette réponse tchize_

Cela corrobore mon ressenti sur le sujet.

Pour info, en fait le programme en question tourne entre la JVM et le serveur de données en local => nous voulions justement éviter des goulets d'étranglements liés au réseau.

Nous n'avions fait le test entre 1 JVM multithreadée et plusieurs JVM monothreadées qu'en vue de déterminer si le problème venait du serveur de données ou du driver utilisé (notre hypothèse à priori).

A propos de la différence entre thread et process, sous ubuntu 10.04, des distinctions sont elles faites ?

De même, est il plus "difficile" pour une seule JVM utilisant plusieurs threads d'utiliser les 4 coeurs que 4 JVMs monothreadées ?

[tchize_]

Pour info, en fait le programme en question tourne entre la JVM et le serveur de données en local => nous voulions justement éviter des goulets d'étranglements liés au réseau.

Ce n'est pas comme ça qu'on recherche les goulots d'étranglement dans une application java. Il est bien plus aisé et les résultat sont bien plus détaillés lorsqu'on utilise un profiler, qui indiquera clairement où le programme prend du temps, où il dort, où il attends le système, etc. Ce genre d'outil permet d'identifier les points chaud de l'application et donc les méthodes / algorithmes qu'il faut remanier pour améliorer les performances.

Nous n'avions fait le test entre 1 JVM multithreadée et plusieurs JVM monothreadées qu'en vue de déterminer si le problème venait du serveur de données ou du driver utilisé (notre hypothèse à priori).

Quel driver?

A propos de la différence entre thread et process, sous ubuntu 10.04, des distinctions sont elles faites ?

De mémoire, aucune relative aux performances. Les threads sont comme des process. Ils sont juste flaggés comem thread pour que certains traitement leur soit spécifique (l'arrêt d'un thread implique l'arret de tous les autres thread du même process, les zones mémoire sont commune donc ne doivent être comptées qu'une fois, les outils comme top ne doivent pas les afficher, les threads ne peuvent pas avoir de gid/uid différents du process)

De même, est il plus "difficile" pour une seule JVM utilisant plusieurs threads d'utiliser les 4 coeurs que 4 JVMs monothreadées ?

Pourquoi? La JVM crée desthreads qui sont gérés par l'ordonanceur de l'OS, ordonnancuer qui prend toutes ses unités d'exécutions, les trie par priorité et donne à chacune du temps CPU. La notion de processus n'interviens pas à ce niveau.

[livenono]

Ce n'est pas comme ça qu'on recherche les goulots d'étranglement dans une application java. Il est bien plus aisé et les résultat sont bien plus détaillés lorsqu'on utilise un profiler, qui indiquera clairement où le programme prend du temps, où il dort, où il attends le système, etc. Ce genre d'outil permet d'identifier les points chaud de l'application et donc les méthodes / algorithmes qu'il faut remanier pour améliorer les performances.

yep, le profiler est la prochaine étape.

Quel driver?

mongodb java driver

plus par là : performance impact with multiple concurrent queries, tout commentaire bienvenu

Edit: le sujet a été évoqué sur le google group mongodb également: mongodb java driver version 2.3 concurrency issue

De mémoire, aucune relative aux performances. Les threads sont comme des process. Ils sont juste flaggés comem thread pour que certains traitement leur soit spécifique (l'arrêt d'un thread implique l'arret de tous les autres thread du même process, les zones mémoire sont commune donc ne doivent être comptées qu'une fois, les outils comme top ne doivent pas les afficher, les threads ne peuvent pas avoir de gid/uid différents du process)

merci

Pourquoi? La JVM crée desthreads qui sont gérés par l'ordonanceur de l'OS, ordonnancuer qui prend toutes ses unités d'exécutions, les trie par priorité et donne à chacune du temps CPU. La notion de processus n'interviens pas à ce niveau.

je le pensais aussi, mais vu le contexte je préfère m'assurer que je ne suis pas à coté de la plaque.

A noter qu'une inspection plus poussée du code du driver indique qu'il utilise des socket pour se connecter à mongodb, configurés ainsi:

Code :

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

1
2
3
4
5
6
7
8
9
 
  _socket = new Socket();
                _socket.connect( _addr , _options.connectTimeout );
 
                _socket.setTcpNoDelay( ! USE_NAGLE );
                _socket.setSoTimeout( _options.socketTimeout );
                _in = new BufferedInputStream( _socket.getInputStream() );
                _out = _socket.getOutputStream();
                return true;

encore merci

[tchize_]

j'ai une question à 10 francs (10 cents): dans ton temps mesuré, tu inclue *aussi* la connexion? Si oui, il serait judicieux de mesurer ce qui se passe quand tu ne fais que des requetes (établir 20 connection puis seulement lancer la mesure sur 20 threads en //). Je dit ça parce que, sur oracle, par exemple, établir une connexion peut mettre jusqu'à 2 secondes, alors qu'effectuer des query sur la connexion établie prend quelques milli secondes.
En général, les pertes de temps dues à l'établissement d'un connexion sont négliegables car on utilise un connexion pool et donc ces connexions sont établies une fois pour toutes sur la durée de vie de l'application.