Système.IO.FileSystemWatcher pour surveiller un dossier réseau-serveur-considérations de Performance

du point de vue de la charge du serveur, en utilisant L'IO.FileSystemWatcher pour les notifications de changement à distance dans le scénario que vous décrivez est probablement la méthode la plus efficace possible. Il utilise les FindFirstChangeNotification et ReadDirectoryChangesW fonctions API Win32 en interne, qui à leur tour communiquer avec le redirecteur réseau d'une manière optimisée (en supposant réseau Windows standard: si un redirecteur tiers est utilisé, et il ne supporte pas les fonctionnalités requises, les choses ne fonctionneront pas du tout). Le .net wrapper utilise également async I / O et tout, assurant ainsi une efficacité maximale.

Le seul problème avec cette solution est qu'elle n'est pas très fiable. Autre que d'avoir à gérer des connexions réseau qui disparaissent temporairement (ce qui n'est pas trop un problème, depuis IO.FileSystemWatcher va lancer un événement d'erreur dans ce cas que vous pouvez gérer), le mécanisme sous-jacent a certains limitations fondamentales. De la documentation MSDN pour les fonctions API Win32:

• ReadDirectoryChangesW échoue avec ERROR_INVALID_PARAMETER lorsque la longueur du tampon est supérieure à 64 KO et que l'application surveille un répertoire sur le réseau. Ceci est dû à une limitation de la taille des paquets avec les protocoles de partage de fichiers sous-jacents

• les Notifications ne peuvent pas être retournées lors de l'appel FindFirstChangeNotification pour un système de fichiers distant

en d'autres termes: sous haute charge (quand vous auriez besoin d'un gros buffer) ou, pire, dans des circonstances aléatoires et non spécifiées, vous pourriez ne pas recevoir les notifications que vous attendez. C'est même un problème avec les observateurs du système de fichiers local, mais c'est beaucoup plus un problème sur le réseau. une autre question ici sur SO détaille les problèmes de fiabilité inhérents avec L'API en un peu plus en détail.

lors de l'utilisation des watchers de système de fichiers, votre application devrait être en mesure de traiter ces limitations. Par exemple:

• si les fichiers que vous recherchez ont des numéros de séquence, stockez le dernier numéro de séquence pour lequel vous avez reçu une notification, afin que vous puissiez rechercher des "lacunes" dans les notifications futures et traiter les fichiers pour lesquels vous n'avez pas reçu de notification;

• à la réception d'un notification, toujours faire un balayage complet du répertoire. Cela peut sembler vraiment mauvais, mais puisque le scan est basé sur des événements, il est encore beaucoup plus efficace que le sondage stupide. Aussi, tant que vous gardez le nombre total de fichiers dans un seul répertoire, ainsi que le nombre de répertoires à analyser, en vertu d'un millier, l'impact de cette opération sur le rendement devrait être assez minime de toute façon.

configurer plusieurs écouteurs est quelque chose que vous devez éviter que autant que possible: si quoi que ce soit, cela rendra les choses même moins fiable...

de toute façon, si vous absolument avez pour utiliser les observateurs de système de fichiers, les choses peuvent fonctionner bien tant que vous êtes au courant des limites, et ne vous attendez pas à une notification 1:1 pour chaque fichier modifié/créé.

donc, si vous avez d'autres options (essentiellement, avoir le processus d'écriture des fichiers vous notifier dans un non-système de fichiers basé façon: n'importe quelle méthode RPC régulière sera une amélioration...), celles-ci valent certainement la peine d'être examinées du point de vue de la fiabilité.