Discussion :

[lavoyech]

Bonjour et bonne année!

En même temps que je commence à me documenter sur le sujet j'en profite pour poser une question globale.

J'ai un programme (vb.net) qui traite des fichiers présents sur un serveur.
Le traitement principal consiste en une première lecture des fichiers présents sur le serveur pour les classer.
La deuxième phase isole les fichiers à traiter.
la troisième phase traite les fichiers prédement isolés les uns après les autres.

Dans le cadre d'une évolution il m'est demandé d'étudier la possibilité de traiter les fichiers en parallèle afin d'accélérer le processus de traitement.
Etant tout à fait novice sur le sujet je me tourne vers vous afin de soliciter vos connaissances pour m'indiquer des pistes, me conseiller des articles ou tutos ou tout simplement m'expliquer comme à un enfant de 5 ans.

Je précise que j'ai déjà commencer à faire des recherches dans lesquelles je me perd un peu et j'essaye ici de glaner du temps et des informations en parallèle de ces recherches justement

Si je ne suis pas assez clair je préciserai au grè de vos remarques.

Cordialement,
Christophe.

[Themacleod1980]

Salut,
le moyen pour lancer plusieurs traitements en "parallèle" est d'utiliser autant de threads qu'il y a traitements à faire.

En gros à la place de ceci :

Code :

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

1
2
3
4
5
6
Foreach(file in mesFiles)//on va dire qu'il y en a 10
{
TraiteMonFichier(file); //on va dire que le traitement dure 5 secondes
//chaque passage attendra que le traitement se termine avant de refaire un passage
}
//les traitements sont traités à la suite, on arrive à 5s*10files = 50 secondes à la fin de la boucle

on fait :

Code :

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

1
2
3
4
5
6
Foreach(file in mesFiles)
{
CréeMoiUnThreadDe(TraiteMonFichier(file)); 
//cette fois ci il lance le traitement mais n'attend pas qu'il se termine pour passer au suivant
}
//on pourrait espérer (mais ce ne sera pas le cas  !) que le traitement durera 5 secondes

on considère que la boucle ne dure plus 50 secondes mais est quasi instantanée car elle n'a pas attendu que chaque traitement se finisse. Par contre les Threads durent encore 5secondes chacun mais sont traités plus ou moins en parallèle et tu ne sais pas trop (tu t'en fout plus ou moins dans ton cas...) quand ils se terminent. (s'il le faut tu peux les synchroniser mais c'est pas un tutoriel là :p)

La fonction CréeMoiUnThreadDe n'existe évidemment pas mais je te laisse chercher les "Thread" et les "ParameterizedThreadStart" comme un grand ^^

[lavoyech]

Merci pour ta réponse.

[worm83]

Bonjour,

Regarde du côté des "Task" plutôt que des "Thread", Task est une classe qui facile l'utilisation des threads, car souvent très mal utilisés, et facilite la mise en œuvre de l'asynchronisme (async await....).

Il y a aussi une solution toute simple pour faire du vrai parallélisme, qui consiste à utiliser la bibliotheque TPL, ce qui reviens à faire ce genre de code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
namespace ConsoleApplication1
{
    class Program
    {
 
 static void Main(string[] args)
        {
            //Recupere l'ensemble des fichier dans le repertoir
            var dir = Directory.GetFiles(@"C:\test");
 
 
           dir.AsParallel().WithDegreeOfParallelism(5).ForAll(x => Console.WriteLine((new FileInfo(x)).Name));
            Console.ReadLine();
        }
   }
}

L'extension Link, AsParallel(), transforme ta collection en une "collection parallélisable". WithDegreeOfParallelism qui n'est pas obligatoire mais à titre d'indication indique le niveau de parallélisme désiré, à savoir que par défaut, PLink va évaluer le meilleur degré pour ton cas. Puis ForAll correspond à l'action à effectuer en parallèle, dans mon cas afficher le nom des fichiers.

[lavoyech]

Merci également!

[champsy_dev]

+1 pour les Task.

Attention avant de te lancer a corps perdu dans la parallélisation de traitement pose ton problème sur le papier.

Il faut en premier lieux identifier les actions , puis définir celle qui peuvent être traiter de façon parallèle de celle qui doivent être traiter sequentielement.

Il faut bien garder a l'esprit qu'accéder a un même objet depuis deux Thread différent leveras un exception. (Sauf type de donné atomique) .

Dans ton exemple :
- Tu liste et tu trie
- Tu analyse et écarté
- Tu traite les fichier non écarté

Pour traiter du doit avoir analyser et pour analyser tu doit avoir lister/trier. Ces trois actions doivent donc s'exécuter de façon séquentiel.

Lister et trier ne peut pas être parallélisé, analyser/écarter peut éventuellement être paralléliser si tu n'as pas besoin de lire un fichier x pour anamyser un fichier a. De même pour traiter les fichier.

[StringBuilder]

Faites gaffe à plusieurs truc :
- Si y'a 50 fichiers à traiter, ne surtout pas lancer 50 threads en même temps ! Vous allez tout bonnement planter la machine, griller le disque, ou je ne sais quoi... Dans l'absolu, je dirais qu'il faut lancer X - 1 threads au maximum, où X est le nombre de coeurs de la machine
- Les process qui accèdent à des ressources physiques (disque dur par exemple) identiques ne doivent pas être parallélisés ! En effet, là où un unique thread fera une lecture séquentielle d'un fichier sur le disque, plusieurs threads vont obliger le disque à lire des brides de plusieurs fichiers chacuns leur tours, réduisant alors drastiquement les performances du disque ! Et quand c'est des process d'écriture de fichiers, je ne vous parle pas de la fragmentation du disque si y'en a plusieurs qui tournent en même temps...

Dans l'absolu, il faut essayer de travailler sur deux disques physiques en même temps, avec trois process :
- Un "fournisseur", qui s'occupe de lire séquentiellement les fichiers
- Un "consommateur", qui s'occupe de faire les calculs/transformations sur les données lues, qui est alors aussi "fournisseur" du troisième process
- Un "consommateur", qui s'occupe d'écrire les données transformées, sur un disque distinct

Et uniquement une fois que ces trois process sont terminés, s'occuper de déplacer les fichiers générés par le troisième vers le disque d'origine.

Donc en gros, séquentiel ou pas, pour du traitement de fichier, c'est de toute façon les IO les plus lentes (généralement) et la parallélisation peut rapidement être source de ralentissement, ce qui n'est pas le but recherché !

[worm83]

Bien sûre StringBuilder, il n'a pas besoin de Parallélisation, mais d'asynchronisme. Pour cela il vaut mieux utiliser Task.
Concernant la librairie TPL, elle optimise le nombre de threads utilisés en interne et s'occupe elle même de synchroniser les données, ce qui ajoute de la sécurité dans son utilisation.