Discussion :

[ZouBi]

Bonjour,

Aujourd'hui, je dispose d'un serveur Glassfish avec une application web impliquant des EJBs.

Je possède un EJB avec une méthode sensée me renvoyer un résultat en temps réel :

• le client se connecte à la page
• la méthode de l'EJB est appelée
• le résultat est affiché sur la page

Cette méthode prend un paramètre, et va faire une recherche dans la base de données pour y effectuer des comparaisons.
Or aujourd'hui, avec la taille actuelle de la base de données (qui ne fait que progresser), cette méthode prend environ 10 secondes pour s'exécuter laissant ainsi le client et la page en attente.

Mon objectif est d'optimiser ce temps, ainsi j'aimerai donc pouvoir "paralléliser" les calculs.
C'est à dire, on a la méthode de l'EJB principal qui va demander à d'autres machines d'un cluster d'effectuer les comparaisons en spécifiant à chacun l'ensemble des données sur lesquelles appliquer l'algorithme.

Cela se ressemble donc à du MapReduce.
Je me suis tourné alors vers Hadoop, mais étant asynchrone, cela semble ne pas etre adapté.
J'ai jeté un coup d'oeil à Storm, qui lui, est synchrone, mais de meme, ne semble ne pas etre adapté à mon soucis.

Quelqu'un connaîtrait-il un moyen simple et efficace pour arriver à mes fins?

[tchize_]

Pour paralléliser, il y a pas le choix, faut pouvoir découper ton calcul en élément indépendants, et ramener tout ça. Mais avant de se lancer là, peux-tu confirmer que le problème est bien au niveau du CPU du serveur J2EE et non pas au niveau de la base de données?


En général, quand je vois des temps de calculs pareils, aujourd'hui, c'est souvent qu'il y a beaucoup trop de requête sur le DB. Typiquement, quand on rapatrie des millions de row pour faire le calcul au lieu de passer 1 journée à crer une requête SQL faisant le calcul. Et souvent on passe de 10 secondes à quelques millisecondes.

Et si c'est coté DB que c'est lent, c'est souvent qu'on a oublié de mettre des indexs quelque part

[ZouBi]

Pour paralléliser, il y a pas le choix, faut pouvoir découper ton calcul en élément indépendants, et ramener tout ça.

Ca c'est ok.

Mais avant de se lancer là, peux-tu confirmer que le problème est bien au niveau du CPU du serveur J2EE et non pas au niveau de la base de données?

C'est bien au niveau CPU. C'est un algorithme lourd de comparaison d'images.
Pour comparer 1000 images qui sont dans la base, la méthode prend 10 secondes.
La récupération des données dans la base prend un temps négligeable.

Je n'ai pas accès au code de l'algorithme, donc je ne peux rien optimiser de ce coté là.

[tchize_]

Une fois que tu as découpé ton travail (par exemple 10 unités de 100 images), il n'y a, je pense, rien de bien compliqué à fournir ce travail à une dixaine de machine. Tu peux, par exemple, sur chaque machine mettre en place un webservice de calcul, et sur la machin maitre invoquer ces services.

Avoir accès à l'aglo pour l'améliorer serait probablement plus efficace, par exemple en précalculant une série d'informations pour chaque image. A voir si c'est faisable suivant l'algo aussi. Aujourd'hui on demande 1000 comparaisons, demain ce sera 5000?

[ZouBi]

Une fois que tu as découpé ton travail (par exemple 10 unités de 100 images), il n'y a, je pense, rien de bien compliqué à fournir ce travail à une dixaine de machine. Tu peux, par exemple, sur chaque machine mettre en place un webservice de calcul, et sur la machin maitre invoquer ces services.

Existe-t-il donc des frameworks adaptés aux EJBs permettant de faire cela avec un peu d'automatisme? C'est à dire qu'on a chaque machine esclave responsable des calculs et la machine maitre ayant automatiquement connaissance du nombre de machines esclaves connectées et sachant répartir les taches?

Avoir accès à l'aglo pour l'améliorer serait probablement plus efficace, par exemple en précalculant une série d'informations pour chaque image. A voir si c'est faisable suivant l'algo aussi. Aujourd'hui on demande 1000 comparaisons, demain ce sera 5000?

Voilà pourquoi il faut que je trouve une solution qui est "scalable" selon le nombre d'images. Je n'ai vraiment pas le choix.

[tchize_]

Bien que tu puisse répartir tes EJBs sur N machines sans grand problèmes, tu ne pourra pas répartir la tâche toi même je pense. Le principe étant que c'est le travail du conteneur. Par exemple, tu peux démarrer un jboss en mode cluster, les EJBs seront présent sur chaque machine et, quand tu demandera N ejbs pour faire N tâches, ils les prendra "dans le cluster", sans certitude que ça impliquera nécessairement une répartition de la charge.

Une solution serait peut être d'utiliser un message driven bean, avec un consommateur sur chaque noeud du cluster. Ainsi tu sépare ton travail en X message et les différents noeuds ont chacun prendre N/X messages pour les traiter.


Tu peux en savoir plus ici sur le clustering de jboss, par exemple:
https://www.jboss.org/jbossclustering/

Mais dans tous les cas, la notion de répartition de charge sera présente dans ton code, pas question de prendre un EJB qui faisait tout en une fois et d'espérer qu'il va magiquement tourner sur 5 machines en même temps comme si tu avait uniquement 5 fois plus de cores.

[ZouBi]

Merci beaucoup.
Je vais me pencher sur le clustering mais de Glassfish. Il semble avoir cette meme fonctionnalité.

Merci encore pour ton aide !