用于监视网络服务器文件夹的System.IO.FileSystemWatcher - 性能注意事项

我想在网络服务器上观看文件夹树以进行更改.这些文件都有特定的扩展名.树中有大约200个文件夹,大约有1200个文件带有我正在观看的扩展名.

我无法写服务在服务器上运行(禁止!)所以解决方案必须是客户端的本地解决方案.及时性并不是特别重要.我可以在通知中花费一分钟或更长时间.我正在关注创建,删除,重命名和更改.

使用.NET System.IO.fileSystemWatcher会在服务器上创建大量负载吗？

10个单独的观察者如何减少正在观看的文件夹/文件的数量？(从700个文件夹中减去200个,从总共5500个文件减少到1200个)更多网络流量而不是更少？我的想法是在服务器上重新洗牌,将观看的文件放在1棵树下.我可能并不总是有这个选项,因此观察团队.

我认为另一个解决方案是定期检查FSW是否在服务器上造成过度负载,或者它是否适用于一大堆SysAdmin类型的原因.

有一个更好的方法吗？

From a server load point of view, using the IO.FileSystemWatcher for remote change notifications in the scenario you describe is probably the most efficient method possible. It uses the FindFirstChangeNotification and ReadDirectoryChangesW Win32 API functions internally, which in turn communicate with the network redirector in an optimized way (assuming standard Windows networking: if a third-party redirector is used, and it doesn't support the required functionality, things won't work at all). The .NET wrapper also uses async I/O and everything, further assuring maximum efficiency.

这个解决方案唯一的问题是它不是很可靠.除了必须暂时处理网络连接(这不是太大的问题,因为IO.FileSystemWatcher将在这种情况下触发你可以处理的错误事件),底层机制有一些基本的限制.从Win32 API函数的MSDN文档:

当缓冲区长度大于64 KB且应用程序正在通过网络监视目录时,ReadDirectoryChangesW失败并返回ERROR_INVALID_PARAMETER.这是由于基础文件共享协议的数据包大小限制

为远程文件系统调用FindFirstChangeNotification时,可能不会返回通知

换句话说:在高负载下(当您需要大缓冲区时),或者更糟糕的是,在随机未指定的情况下,您可能无法获得预期的通知.这甚至是本地文件系统观察者的问题,但它在网络上更是一个问题.关于SO的另一个问题详细介绍了API的固有可靠性问题.

使用文件系统观察程序时,您的应用程序应该能够处理这些限制.例如:

如果您要查找的文件具有序列号,请存储您收到通知的最后序列号,这样您就可以在将来的通知中查找"间隙"并处理您未收到通知的文件;

收到通知后,请始终执行完整目录扫描.这可能听起来很糟糕,但由于扫描是事件驱动的,它仍然比哑巴轮询更有效.此外,只要保留单个目录中的文件总数以及要扫描的目录数量(大约一千个左右),此操作对性能的影响应该非常小.

设置多个听众是你应该尽可能避免的:如果有的话,这将使事情变得更不可靠......

无论如何,如果你绝对必须使用文件系统观察者,只要你意识到这些限制就可以正常工作,并且不希望每个修改/创建的文件都有1:1的通知.

所以,如果你有其他选择(基本上,让编写文件的进程以非文件系统的方式通知你:任何常规的RPC方法都会有所改进......),那些从可靠性点来看绝对值得研究观点.

我曾经多次使用C#的文件系统观察者.我第一次使用它们时,我遇到了停止工作的问题,主要是因为我正在处理报告更改的线程中的更改.

然而,现在,我只是将更改推送到队列并在另一个线程上处理队列.这似乎解决了我原来的问题.对于您的问题,您可以让多个观察者进入同一队列.

但是,我没有用你的问题来解决这个问题.