Problème de multithreading

Version imprimable

Voir 40 message(s) de cette discussion en une page

1 pièce(s) jointe(s)

Problème de multithreading

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
public void run()
    {
        try {
 
            // .......................
 
        writerFileHTML(rH.responseRequest(), "responseHtml" + (i + 1) + ".html");
 
        result += formater.format(date) + "," + url + post + "," + product.get(i) + "," + rH.getTimeRequest();
        // if (result != null && existFile == false)
        csvOutput.write(formater.format(date));
        csvOutput.write(url + post);
        csvOutput.write(product.get(i));
        csvOutput.write(String.valueOf(rH.getTimeRequest()));
        csvOutput.endRecord();
 
        System.out.println(result);
 
    }
    catch (Exception e) {
        // System.out.println(e.toString());
 
    }
}

Exécution du Thread de la méthode run

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
public static void main(String[] args) throws Exception
{
        // ........................
 
 
                tabSimu = new Simulateur[nombreDeThread];
        csvOutput = new CsvWriter(new FileWriter(outputFile, true), ',');
        for (i = 0; i < nombreDeThread; i++)
        {
 
            beginDate = formater.parse(arrayListeDate.get(i));
            Date currentDate = formater.parse(arrayListeDate.get(i + 1));
 
            duree = (currentDate.getTime() - beginDate.getTime());
 
            // TODO Auto-generated catch block
 
            // System.out.print(duree);
            tabSimu[i] = new Simulateur();
            tabSimu[i].start();
            Thread.sleep(duree);
        }
// ..........................
}

Lorsque des requêtes s'exécute en même temps, il y a les mêmes requêtes qui s'exécute alors qu'il doit exécuter une autre requête, je pense que dans mon tableau de Thread chaque Thread entre en collision.

Pouvez-vous m'aider svp? Merci!!!

Cordialement.

04/10/2017, 10h34
thelvin

Hello,

oui c'est un peu normal que des threads entrent en collision quand on s'arrange pas pour qu'ils ne le fassent pas, puisque le principe des threads c'est qu'ils s'exécutent en même temps et pas l'un après l'autre.

Mais on va pas deviner ce que c'est tes histoires de requêtes, là. L'important c'est comment tes threads choisissent le prochain travail qu'ils font. S'ils font ça tous en même temps ils vont choisir le même travail, entre autres. Normal.
04/10/2017, 10h47
vLemaistre

Citation:

Envoyé par thelvin

Hello,

oui c'est un peu normal que des threads entrent en collision quand on s'arrange pas pour qu'ils ne le fassent pas, puisque le principe des threads c'est qu'ils s'exécutent en même temps et pas l'un après l'autre.

Mais on va pas deviner ce que c'est tes histoires de requêtes, là. L'important c'est comment tes threads choisissent le prochain travail qu'ils font. S'ils font ça tous en même temps ils vont choisir le même travail, entre autres. Normal.

D'accord, merci mais ça ne me dit pas comment régler ce problème. Quelle classe utiliser et quelles méthodes ou une librairie?
04/10/2017, 14h38
joel.drigo
Salut,

Ta description n'est pas assez précise pour qu'on comprenne exactement ce que ton programme doit faire. A priori, de ce que je comprends, tu as un ensemble de requêtes que tu veux faire traiter par plusieurs threads.
1. Solution à la mano : avoir une liste de requêtes, et gérer les accès concurrents sur cette liste. A la base, il y a le mot clef synchronized qui permet de créer un bloc, ou une méthode, qui ne pourra être exécuté par plusieurs threads différents en même temps. Si le code s'occupe de prendre une requête dans la liste de requête (en l'enlevant de cette liste), aucun thread ne pourra pas traiter une requête traitée par un autre, en pensant à la problématique d'éviter qu'un thread ne tourne à vide (en consommant du cpu pour rien) quand il n'y a pas de requête en attente de traitement
  Il y a également des classes qui implémentent directement ce principe (voir les BlockingQueue par exemple), en gérant l'attente des threads.
2. Solution plus simple, utiliser un service d'exécution qui a un pool de threads : voir Executors.newFixedThreadPool(nbThreads). Ou selon le cas, d'autres type de services d'exécution (il y en a par exemple qui crée un thread par tâche, et qui a un intérêt lorsqu'il y a beaucoup de requêtes, mais qu'elles sont courtes en terme d'exécution (sinon, on risque une augmentation importante du nombre de threads concurrents). En plus ces classes facilite la récupération de résultat différé.
3. Voir aussi les capacités de la classe Stream en terme de parallélisation.
04/10/2017, 14h47
vLemaistre

Merci pour ta réponse, je suis en train d'essayer la 2ème solution avec Executors
05/10/2017, 10h33
vLemaistre
Citation:
Envoyé par joel.drigo

Salut,

Ta description n'est pas assez précise pour qu'on comprenne exactement ce que ton programme doit faire. A priori, de ce que je comprends, tu as un ensemble de requêtes que tu veux faire traiter par plusieurs threads.

Solution à la mano : avoir une liste de requêtes, et gérer les accès concurrents sur cette liste. A la base, il y a le mot clef synchronized qui permet de créer un bloc, ou une méthode, qui ne pourra être exécuté par plusieurs threads différents en même temps. Si le code s'occupe de prendre une requête dans la liste de requête (en l'enlevant de cette liste), aucun thread ne pourra pas traiter une requête traitée par un autre, en pensant à la problématique d'éviter qu'un thread ne tourne à vide (en consommant du cpu pour rien) quand il n'y a pas de requête en attente de traitement
Il y a également des classes qui implémentent directement ce principe (voir les BlockingQueue par exemple), en gérant l'attente des threads.
Solution plus simple, utiliser un service d'exécution qui a un pool de threads : voir Executors.newFixedThreadPool(nbThreads). Ou selon le cas, d'autres type de services d'exécution (il y en a par exemple qui crée un thread par tâche, et qui a un intérêt lorsqu'il y a beaucoup de requêtes, mais qu'elles sont courtes en terme d'exécution (sinon, on risque une augmentation importante du nombre de threads concurrents). En plus ces classes facilite la récupération de résultat différé.
Voir aussi les capacités de la classe Stream en terme de parallélisation.
J'ai utilisé Executors.newFixedThreadPool(nbThreads), le problème c'est que j'ai + de 1000 requêtes http à exécuter et un maximum de 10 requêtes / sec
selon des durées, je ne sais pas combien utilisé de Thread et ou mettre une tempo?
05/10/2017, 10h58
joel.drigo

Citation:

Envoyé par vLemaistre

un maximum de 10 requêtes / sec

Tu veux dire que ton serveur ne te permet pas plus de 10 requêtes par seconde et il te bloque si tu dépasses ?
05/10/2017, 11h00
vLemaistre

Citation:

Envoyé par joel.drigo

Tu veux dire que ton serveur ne te permet pas plus de 10 requêtes par seconde et il te bloque si tu dépasses ?

Il exécute une autre requête mais pas dans le même temps
05/10/2017, 11h04
joel.drigo

Je ne comprends pas ce que tu veux dire. Il, le serveur ? Quelle autre requête ? Quel rapport avec les requêtes exécutées par le service d'exécution ? Tu peux me décrire l'algorithme complet ? Les entrées, les sorties, les contraintes...
05/10/2017, 11h12
vLemaistre

Citation:

Envoyé par joel.drigo

Je ne comprends pas ce que tu veux dire. Il, le serveur ? Quelle autre requête ? Quel rapport avec les requêtes exécutées par le service d'exécution ? Tu peux me décrire l'algorithme complet ? Les entrées, les sorties, les contraintes...

le temps d’exécution que je dois avoir entre chaque requête:
2017-06-12 11:00:00
2017-06-12 11:00:01
2017-06-12 11:00:04
2017-06-12 11:00:05
2017-06-12 11:00:05
2017-06-12 11:00:08
2017-06-12 11:00:10
2017-06-12 11:00:10
2017-06-12 11:00:11
2017-06-12 11:00:14

Resultat que j'ai:
2017-10-05 11:08:35
2017-10-05 11:08:49
2017-10-05 11:08:49
2017-10-05 11:08:48
2017-10-05 11:08:48
2017-10-05 11:08:48
2017-10-05 11:08:48
2017-10-05 11:08:49
2017-10-05 11:08:48
2017-10-05 11:08:49

C'est plus clair?
05/10/2017, 11h22
joel.drigo

Citation:

Envoyé par vLemaistre

C'est plus clair?

Pas vraiment. Parce que là, si je me base juste sur ce que tu viens de me me montrer, j'ai l'impression que tu dois exécuter des requêtes les unes après les autres et je ne vois plus trop le rapport avec le fait d'en exécuter plusieurs en même temps.

Pour exécuter quelque choses à intervalle régulier, il y a la classe Timer. Ou un service d'exécution de type ScheduledExecutorService (qu'on peut obtenir par Executors.newScheduledThreadPool()).
05/10/2017, 11h27
vLemaistre

Citation:

Envoyé par joel.drigo

Pas vraiment. Parce que là, si je me base juste sur ce que tu viens de me me montrer, j'ai l'impression que tu dois exécuter des requêtes les unes après les autres et je ne vois plus trop le rapport avec le fait d'en exécuter plusieurs en même temps.

Pour exécuter quelque choses à intervalle régulier, il y a la classe Timer. Ou un service d'exécution de type ScheduledExecutorService (qu'on peut obtenir par Executors.newScheduledThreadPool()).

Oui excuse moi, je me suis surement mal expliqué, oui il faut exécuter les requêtes les une après les autres sauf quelques une qui s’exécute en même temps comme par exemple: 2017-06-12 11:00:05
2017-06-12 11:00:05
05/10/2017, 11h50
joel.drigo

Ah, oui, ça se complique. Et c'est quoi le critère pour déterminer celles qu'il faut exécuter en même temps ? Et la raison ? Parce que "l'exécution en même temps", en client/serveur, c'est un concept quelque peu illusoire (entre le délai dû au transport, des temps d'accès aux ressources, de la disponibilité même des ressources dans un contexte d'accès multiple, la notion simulée de "temps réel", et les différences de temps d'exécution des requêtes en elle-même, etc). Ton système est-il seulement mono utilisateur ?
05/10/2017, 11h55
vLemaistre

Citation:

Envoyé par joel.drigo

Ah, oui, ça se complique. Et c'est quoi le critère pour déterminer celles qu'il faut exécuter en même temps ? Et la raison ? Parce que "l'exécution en même temps", en client/serveur, c'est un concept quelque peu illusoire (entre le délai dû au transport, des temps d'accès aux ressources, de la disponibilité même des ressources dans un contexte d'accès multiple, la notion simulée de "temps réel", et les différences de temps d'exécution des requêtes en elle-même, etc). Ton système est-il seulement mono utilisateur ?

Je lis un fichier csv, avec les temps que j'ai mis dans une arraylist, j'ai fait l'indice en cours - l'indice d'avant, ce qui me donne le temps d’exécution entre chaque requête
05/10/2017, 12h01
joel.drigo

Citation:

Envoyé par vLemaistre

Je lis un fichier csv, avec les temps que j'ai mis dans une arraylist, j'ai fait l'indice en cours - l'indice d'avant, ce qui me donne le temps d’exécution entre chaque requête

Ça me dit juste comment tu paramètres ton système, pas pourquoi tu le paramètres et quel est son objectif fonctionnel et/ou technique ? Peu importe si les paramètres viennent d'un csv, d'une base de données ou d'un capteur physique, si je ne sais pas quel est le but (quelles entrées on a (au sens fonctionnel, pas technique, fichier ou autre, c'est secondaire), quelles sorties on veut, et comment passer des unes au autres), je ne vois pas trop comment dire comment l'atteindre.
05/10/2017, 12h06
vLemaistre

Citation:

Envoyé par joel.drigo

Ça me dit juste comment tu paramètres ton système, pas pourquoi tu le paramètres et quel est son objectif fonctionnel et/ou technique ? Peu importe si les paramètres viennent d'un csv, d'une base de données ou d'un capteur physique, si je ne sais pas quel est le but (quelles entrées on a (au sens fonctionnel, pas technique, fichier ou autre, c'est secondaire), quelles sorties on veut, et comment passer des unes au autres), je ne vois pas trop comment dire comment l'atteindre.

Le but c'est de simuler des utilisateurs qui font des recherches sur un site et donc pour cela je lis un fichier csv qui lance des requêtes à la place des utilisateurs, pour par la suite vérifier si le site à des problèmes (plantage).
05/10/2017, 15h53
joel.drigo

Pourquoi tu n'utilises pas JMeter pour faire ton test ?
05/10/2017, 16h16
vLemaistre

Citation:

Envoyé par joel.drigo

Pourquoi tu n'utilises pas JMeter pour faire ton test ?

Parce que je suis en stage de dev dans une entreprise et que JMeter ne leur correspond pas.
05/10/2017, 17h02
joel.drigo
C'est pourtant un peu fait pour ça JMeter.

Donc, en gros, si je résume,
- tu veux pouvoir à intervalle régulier (toutes les 500 ms par exemple) lancer une action qui lance de une à plusieurs requêtes "simultanément".
- Ou alors il faut faire ça selon un plan précis (genre je lance une requête à 0+500ms, j'en lance une 0+1000ms, j'en lance 2 à 0+1500s, etc...
- ou alors tu veux simuler n utilisateurs (qui vont avoir chacun leur thread) qui ont chacun un scénario qui consiste en l'un des deux cas précédents ?
Est-ce qu'il faut attendre qu'un lot de requêtes soit terminé avant de lancer le suivant ?
05/10/2017, 17h22
vLemaistre
Citation:
Envoyé par joel.drigo

C'est pourtant un peu fait pour ça JMeter.

Donc, en gros, si je résume,

tu veux pouvoir à intervalle régulier (toutes les 500 ms par exemple) lancer une action qui lance de une à plusieurs requêtes "simultanément".
Ou alors il faut faire ça selon un plan précis (genre je lance une requête à 0+500ms, j'en lance une 0+1000ms, j'en lance 2 à 0+1500s, etc...
ou alors tu veux simuler n utilisateurs (qui vont avoir chacun leur thread) qui ont chacun un scénario qui consiste en l'un des deux cas précédents ?

Est-ce qu'il faut attendre qu'un lot de requêtes soit terminé avant de lancer le suivant ?
Oui sur un plan précis, par exemple à
17:00:00 une requête
17:00:04 une autre requête
17:00:05 une autre requête
17:00:05 une autre requête
17:00:08 une autre requête
17:00:10 une autre requête
17:00:10 une autre requête
17:00:14 une autre requête

Voir 40 message(s) de cette discussion en une page