Discussion :

[BaBuX]

Bonjour,
si je ne suis pas dans le bon topic merci de me déplacer.

Un collègue a développé un programme batch java mettant 8 heures à s’exécuter. Ce programme fait tourné 10 threads (chaque thread s'exécute en 8 heures) et il démarre ses threads toutes les deux secondes.
Il dit que c'est pour que le serveur gére mieux sa montée en charge.

Qu'en pensez vous ?

[thelvin]

Ça dépend de ce qui est fait exactement par le batch.

Personnellement, je préfère attendre un signal précis, comme le fait d'avoir atteint telle étape représentant une bonne partie de la montée en charge, plutôt qu'attendre deux secondes. Mais c'est limite un détail.

[BaBuX]

Le batch fait du traitement de données sur une base PostgreSQL.
Mais je ne comprend pas bien ce que çà change de faire çà au lieu de démarrer tous les thread en même temps, de toute façon ils s’exécutent tous pendant 8 heures.

En gros ma question c'est .... j'ai 3 threads
A et B et C, mettant chacun un certain temps à s'executer (plusieurs heures)

Est ce que faire
A()
sleep(2s)
B()
sleep(2s)
C()

est plus efficace ? et si oui pourquoi et à quel niveau ?

que de faire
A()
B()
C()

ps(A et B et C s’exécute en parallèle bien sur)

[dinobogan]

Avec si peu d'information, impossible de donner une réponse définitive, mais il semblerait que ça ne sert à rien.

[BaBuX]

Et est ce çà pourrait servir dans certains cas ?

[thelvin]

Ce n'est pas complètement impossible.

Mais si c'est le cas, il serait plus propre d'attendre un signal précis, plutôt qu'un nombre de secondes.

[BaBuX]

Si quelqu'un a un exemple d'utilisation de ce genre de méthodes je suis preneur. En attendant vu ce que j'ai vu dans son code je considère que ça ne vaut pas un clou. Et dire que çà tourne en production sur une grosse enseigne de la grande distribution du nord de la France en 5 lettres. Mais loin d'être amicale ... héhé

[dinobogan]

Et est ce çà pourrait servir dans certains cas ?

Chaque cas est unique. Voici une possibilité que j'ai connue sur un projet : le thread doit charger des données de paramétrage en base. Des processus critiques fonctionnent en permanence à côté des threads. Un chargement massif des données sur les thread diminue grandement les performances des processus critiques en mettant des contentions sur les tables de paramétrages. Il faut donc y aller mollo et lancer les threads avec quelques secondes d'intervalle.

Dans ton cas, si aucun processus critique en terme de temps de réponse n'existe et/ou si les threads ne font rien de spécial autre que leur traitement pendant les 2 premières secondes au démarrage, alors la pause est inutile.