J'ai une application qui fonctionne bien pour le traitement de fichiers qui atterrissent dans un répertoire sur mon serveur. Le processus est le suivant:
1) check for files in a directory 2) queue a user work item to handle each file in the background 3) wait until all workers have completed 4) goto 1
4 Réponses :
Je suggérerais de conserver une liste de fichiers que vous traitez actuellement. Demandez au fil de se retirer de cette liste lorsque le fil se termine. Lorsque vous recherchez de nouveaux fichiers, excluez ceux de la liste actuellement en cours.
Comment gardez-vous une trace de laquelle les fichiers ont été traités après leur retrait de la file d'attente de fil?
Il a déjà ce problème, alors je suppose que cela est déjà résolu par, par exemple, le fichier étant supprimé à la fin du processus.
Oui, c'est essentiellement ce que je pensais - espérait simplement qu'il y avait un paradigme de producteur-consommateur existant qui est jugé et vrai plutôt que de rouler le mien. Merci.
Déplacez les fichiers dans un répertoire de traitement avant de commencer les threads. Ensuite, vous pouvez tirer et oublier les threads et tout administrateur peut voir en un coup d'œil ce qui se passe.
Cela suppose qu'il peut même faire cela sur le serveur, mais j'aime cette idée parce que vous savez quels fichiers qui doivent être / sont / ont été traités en vertu d'eux dans leurs répertoires respectifs.
La frayer un fil par objet à traiter n'est presque jamais une bonne approche. Dans votre cas lorsque le nombre de fichiers ira au-dessus de plusieurs centaines d'un seul thread-par-fichier rendra la performance d'application plutôt mauvaise et avec un processus 32 bits commencera à court d'espace d'adresses.
La solution de liste de Falcon sombre est assez simple et correspond à votre algorithme. J'utiliserais réellement la file d'attente (Concurrentqueue - http://msdn.microsoft.com/ FR-US / Bibliothèque / DD267265.aspx ) Pour mettre des éléments à traiter d'un côté (c'est-à-dire sur la base des analyses périodiques de l'observateur de fichiers) et choisissez des éléments de traitement par un ou plusieurs threads de l'autre côté. Vous voulez généralement un nombre plus petit de threads (I.e. 1-2x Nombre de CPU pour la charge intensive de la CPU).
Envisagez également d'utiliser la bibliothèque parallèle de tâche (comme parallèle.foreach - http: // msdn.microsoft.com/en-us/library/dd989744.aspx ) Pour faire face à plusieurs threads.
Pour minimiser le nombre de fichiers à gérer, je garderais une liste des éléments qui sont déjà traités - chemin de fichier + Date de dernière modification (sauf si vous pouvez obtenir ces informations à partir d'autres sources).
Mes deux questions principales seraient:
Selon votre réponse, je pourrais aller avec l'algorithme de consommateur de producteur suivant:
Je pense que c'est une bonne combinaison de comportement non bloquant et faible d'utilisation de la CPU. Mais mesurez vos résultats avant et après. Je vous recommanderais d'utiliser le threadpool et essayez de garder les threads de blocage (c'est-à-dire essayer d'assurer la réutilisation du fil en ne faisant pas blocage en faisant quelque chose comme thread.sleep)
Notes:
Qu'advient-il d'un fichier après sa traité? reste-t-il dans le même répertoire? Supprimé? déplacé? De plus, les fichiers sont-ils largués dans le répertoire serveur nommé systématiquement avec la même extension?
Je ne comprends pas comment votre processus comme indiqué ci-dessus empêche les fichiers d'être traité deux fois.
Une fois qu'un fichier est traité, il est supprimé à l'étape 2, c'est pourquoi, après la fin de l'étape 3, tous les fichiers du dossier devraient être traités et n'ont pas été traités précédemment.