JVM et accès à la couche TCP: des limitations ?

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:

Citation:

---

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

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.

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 ?

Citation:

---

Envoyé par livenono

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.

Citation:

---

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?

Citation:

---

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)

Citation:

---

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.

Citation:

---

Envoyé par tchize_

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.

Citation:

---

Envoyé par tchize_

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

Citation:

---

Envoyé par tchize_

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 :)

Citation:

---

Envoyé par tchize_

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:

---

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

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.

re bonjour tchize_ :)

et encore merci !

le temps mesuré est en effet le temps global de la requête.

toutefois le driver java mongodb inclut un pool de 10 (par défaut) connexions. donc cela ne devrait pas jouer

pour info, chaque requête implique la construction d'une liste de documents de 600kb (ou de 100 fois 6kb), sachant que ce sont essentiellement des associations clés/valeurs avec clé sous forme de string et valeur sous forme de type primitif (ou string).

Dans l'issue indiquée, d'ailleurs, réduire une partie du volume de données n'avait pas eu d'impact particulier sur la montée en charge, malgré un volume de données transféré inférieur à 6Kb => on passait de 4ms à 7ms pour 1 à 4 threads (temps mesurés avec System.nanotime() donc précis au ms).

si jamais vous avez des avis sur les performances rencontrées, je suis preneur.

En effet je ne suis pas expert de "scalabilité mongodb", mais j'ai tout de même été surpris par le manque de "scalabilité": plusieurs requêtes concurrentes ruinent vraiment les performances.

Citation:

---

Envoyé par livenono

malgré un volume de données transféré inférieur à 6Kb => on passait de 4ms à 7ms pour 1 à 4 threads (temps mesurés avec System.nanotime() donc précis au ms).

---

Ca c'est faux. Ce qu'il faut c'est mesurer sur un ensemble de requête. Il suffit que n'importe quoi dans l'OS se soit activé en // (un coup de swap, un coup de flush des logs, un coup de check réseau dhcp) pour influencer un calcul de quelque millisecondes. Si tu me disais que pour faire 1000 fois l'opération vous êtes passé de 4 à 7 secondes, alors oui, la mesure serait fiable. Des différences instantanée de 3ms ne veulent rien dire et ne sont pas signficative de la mesure de performance, sachant que votre mesure sera valable avec une fourchette moyenne de 50 à 100ms en fonction du reste de la charge de l'OS et des perfs de la machine.

Citation:

---

Envoyé par tchize_

Si tu me disais que pour faire 1000 fois l'opération vous êtes passé de 4 à 7 secondes, alors oui, la mesure serait fiable.

---

tout doux ;)

comme tu as pu le voir sur le ticket Jira, on a en effet essayé sur plus d'une requête, à savoir 400 par test sur les valeurs données en début de ticket (on a fait d'autres tests avec plus sans que cela ne change significativement les résultats).

merci encore tout de même :)

j'ai pas regardé en détails le ticket ;)

Citation:

---

Envoyé par tchize_

j'ai pas regardé en détails le ticket ;)

---

lol

bien possible en effet :)

en substance, les perfs (mesurées sur 400 requetes réparties parmi les différents threads) varient comme suit:
Pour moins de 6Kb au total par requete :
- thread pool de 1: 4ms/requete, 1871ms au total
- thread pool de 4: 7ms/requete, 797ms
- thread pool de 10: 20ms/requete, 815ms
- thread pool de 20: 34ms/requete, 759ms
Pour 600Kb par requête:
- thread pool de 1: 52ms/requete, 21063ms au total
- thread pool de 4: 168ms/requete, 16871ms
- thread pool de 10: 544ms/requete, 22081ms
- thread pool de 20: 1025ms/requete, 20754ms

l'explication à ces chutes de perf étant à priori un pb de stack TCP...

bon, pour info, il y a des soucis dans ce driver indépendamment de la stacl tcp:
le dernier commentaire dit en effet; http://jira.mongodb.org/browse/JAVA-207

Citation:

---

in fact, this seems like a finalization/GC issue. if you use the 2.3 release driver and remove the finalize() methods from DBApiLayer, the cores avail are used to 100% and the numbers created are significantly better.

i think this is due to implicit sync on finalization. Could we somehow get away without finalization there?

---

lol