System.IO.FileSystemWatcher لمراقبة مجلد خادم الشبكة - اعتبارات الأداء

Question

أريد مشاهدة شجرة المجلدات على خادم الشبكة لإجراء التغييرات.جميع الملفات لها امتداد محدد.يوجد حوالي 200 مجلد في الشجرة وحوالي 1200 ملف بالامتداد الذي أشاهده.

لا يمكنني كتابة خدمة لتشغيلها على الخادم (خارج الحدود!) لذا يجب أن يكون الحل محليًا للعميل.التوقيت ليس مهما بشكل خاص.يمكنني العيش مع تأخير لمدة دقيقة أو أكثر في الإشعارات.أنا أشاهد الإنشاء والحذف وإعادة التسمية والتغييرات.

هل سيؤدي استخدام .NET System.IO.fileSystemWatcher إلى إنشاء حمل كبير على الخادم؟

ماذا عن 10 مراقبين منفصلين لتقليل عدد المجلدات/الملفات التي تتم مراقبتها؟(وصولاً إلى 200 من 700 مجلد، و1200 من 5500 ملف إجمالاً) المزيد من حركة مرور الشبكة بدلاً من تقليلها؟أفكاري هي تعديل وزاري على الخادم لوضع الملفات التي تمت مشاهدتها تحت شجرة واحدة.قد لا يكون لدي هذا الخيار دائمًا ومن هنا جاء فريق المراقبين.

أفترض أن الحل الآخر هو إجراء فحص دوري إذا قام FSW بإنشاء تحميل غير ضروري على الخادم، أو إذا لم يعمل لمجموعة كاملة من أسباب نوع SysAdmin.

هل هناك طريقة أفضل للقيام بذلك؟

Answer 1

من وجهة نظر تحميل الخادم، باستخدام IO.FileSystemWatcher من المحتمل أن تكون إشعارات التغيير عن بعد في السيناريو الذي تصفه هي الطريقة الأكثر فعالية الممكنة.يستخدم FindFirstChangeNotification و قراءة دليل التغييراتW تعمل Win32 API داخليًا، والتي بدورها تتواصل مع معيد توجيه الشبكة بطريقة محسنة (بافتراض شبكة Windows القياسية:إذا تم استخدام معيد توجيه تابع لجهة خارجية، وهو لا يدعم الوظيفة المطلوبة، فلن تعمل الأمور على الإطلاق).يستخدم برنامج .NET أيضًا عمليات الإدخال/الإخراج غير المتزامنة وكل شيء، مما يضمن أقصى قدر من الكفاءة.

المشكلة الوحيدة في هذا الحل هي أنه غير موثوق للغاية.بخلاف الاضطرار إلى التعامل مع اتصالات الشبكة التي تختفي مؤقتًا (وهو ما لا يمثل مشكلة كبيرة، نظرًا لأن IO.FileSystemWatcher سيطلق حدث خطأ في هذه الحالة والذي يمكنك التعامل معه)، فإن الآلية الأساسية لها بعض القيود الأساسية.من وثائق MSDN لوظائف Win32 API:

• قراءة دليل التغييراتW يفشل مع ERROR_INVALID_PARAMETER عندما يكون طول المخزن المؤقت أكبر من 64 كيلو بايت ويقوم التطبيق بمراقبة دليل عبر الشبكة.ويرجع ذلك إلى قيود حجم الحزمة مع بروتوكولات مشاركة الملفات الأساسية

• قد لا يتم إرجاع الإخطارات عند الاتصال FindFirstChangeNotification لنظام الملفات البعيد

بعبارة أخرى:في ظل التحميل العالي (عندما تحتاج إلى مخزن مؤقت كبير)، أو ما هو أسوأ من ذلك، في ظل ظروف عشوائية غير محددة، قد لا تحصل على الإشعارات التي تتوقعها.وهذه مشكلة تتعلق بمراقبي نظام الملفات المحليين، ولكنها مشكلة أكبر بكثير عبر الشبكة. سؤال آخر هنا على SO تفاصيل مشاكل الموثوقية المتأصلة في واجهة برمجة التطبيقات (API) بمزيد من التفصيل.

عند استخدام مراقبي نظام الملفات، يجب أن يكون تطبيقك قادرًا على التعامل مع هذه القيود.على سبيل المثال:

• إذا كانت الملفات التي تبحث عنها تحتوي على أرقام تسلسلية، فقم بتخزين آخر رقم تسلسل تم إعلامك به، حتى تتمكن من البحث عن "الثغرات" في الإشعارات المستقبلية ومعالجة الملفات التي لم يتم إعلامك بها؛

• عند تلقي إشعار، قم دائمًا بإجراء فحص كامل للدليل.قد يبدو هذا سيئًا حقًا، ولكن نظرًا لأن الفحص يعتمد على الأحداث، فإنه لا يزال أكثر كفاءة من الاستطلاعات الغبية.أيضًا، طالما أنك تحتفظ بالعدد الإجمالي للملفات في دليل واحد، بالإضافة إلى عدد الدلائل المطلوب فحصها، أقل من ألف أو نحو ذلك، فإن تأثير هذه العملية على الأداء يجب أن يكون ضئيلًا جدًا على أي حال.

يعد إعداد مستمعين متعددين أمرًا يجب عليك تجنبه قدر الإمكان:إذا كان هناك أي شيء، فهذا سيجعل الأمور متساوية أقل موثوق...

على أية حال، إذا كنت على الاطلاق يملك لاستخدام مراقبي نظام الملفات، يمكن أن تعمل الأمور بشكل جيد طالما أنك على دراية بالقيود، ولا تتوقع إشعارًا 1:1 لكل ملف تم تعديله/إنشاءه.

لذا، إذا كان لديك خيارات أخرى (بشكل أساسي، فإن عملية كتابة الملفات تُعلمك بطريقة لا تعتمد على نظام الملفات:أي طريقة RPC عادية ستكون بمثابة تحسين...)، فهي بالتأكيد تستحق النظر فيها من وجهة نظر الموثوقية.

Answer 2

لقد استخدمت مراقبي نظام الملفات من C# عدة مرات.في المرة الأولى التي استخدمتها فيها، واجهت مشاكل في توقفها عن العمل، ويرجع ذلك أساسًا إلى حقيقة أنني كنت أعالج التغييرات في سلسلة الرسائل التي أبلغت عن التغيير.

ومع ذلك، الآن، أقوم فقط بدفع التغيير إلى قائمة الانتظار ومعالجة قائمة الانتظار في مؤشر ترابط آخر.يبدو أن هذا يحل المشكلة التي واجهتني في الأصل.بالنسبة لمشكلتك، قد يكون لديك عدة مراقبين يضغطون على نفس قائمة الانتظار.

ومع ذلك، لم أستخدم هذا مع حجم المشكلة لديك.

Answer 3

في تجربتي، لا يؤدي FSW إلى إنشاء حركة مرور عالية على الشبكة.ومع ذلك، إذا كانت هناك مشكلة في الأداء، فإن أسلوبك في استخدام العديد من المراقبين وتقسيمهم إلى عدد أقل من المجلدات التي تتم مراقبتها يبدو معقولاً.

لقد واجهت بعض المشكلات الكبيرة مع FSW على محركات أقراص الشبكة، على الرغم من ذلك:يؤدي حذف ملف دائمًا إلى ظهور حدث الخطأ، وليس الحدث المحذوف أبدًا.لم أجد حلاً، لذا أتجنب الآن استخدام FSW إذا كان هناك طريقة للتغلب عليه...

Answer 4

ال تشير وثائق MSDN أنه يمكنك استخدام مكون FileSystemWatcher لمراقبة تغييرات نظام الملفات على الشبكة يقود.

ويشير أيضًا إلى أن مكون المراقبة يستمع إلى إشعارات تغيير نظام الملفات بدلاً من استجواب محرك الأقراص الهدف بشكل دوري لمعرفة التغييرات.

بناءً على ذلك، يعتمد مقدار حركة مرور الشبكة بشكل كامل على مقدار التغيير الذي تتوقعه لمحتويات محرك أقراص الشبكة هذا.لن يضيف مكون FSW إلى مستوى حركة مرور الشبكة.

Answer 5

يبدو المراقب موثوقًا بنسبة 100% - ما عليك سوى مشاهدة حجم المخزن المؤقت على كائن المراقب.لقد اختبرت الآلاف من تحديثات الملفات، ولم أفقد أيًا منها.

أوصي باستخدام نهج متعدد الخيوط - المشغل هو مراقب الملفات.يمكنه إطلاق سلسلة رسائل لكل تغيير ملف تم اكتشافه.يمكن أن يعالج المراقب أسرع بكثير مع فرصة أقل للتفوق.(استخدم مؤشر الترابط غير المتزامن)

Answer 6

بعد استخدام System.IO.FileSystemWatcher لبعض الوقت.إنه ليس مستقرًا بدرجة كافية للتعامل مع الأحداث التي تأتي بسرعة كبيرة.لضمان قراءة 100% للملفات.أستخدم طرق دليل بسيطة للبحث في الملفات.بعد قراءته، قم بنسخ الملفات على الفور إلى مجلد آخر.لعزله عن الملفات الجديدة التي يتم إضافتها أثناء قراءتك للملفات.

يستخدم الموقت لقراءة المجلد بانتظام.عن طريق نسخ الملف المقروء بالفعل إلى مجلد الأرشيف، فهذا يضمن عدم قراءته مرة أخرى.ستكون القراءة اللاحقة دائمًا ملفات جديدة.

var fileNames = Directory.GetFiles(srcFolder);
foreach (string fileName in fileNames)
{
   string[] lines = File.ReadAllLines(fileName);
}

Answer 7

لا أعتقد أن هناك أي نوع من الحالة النشطة أو الاتصال بين الكمبيوتر المزود بـ FSW والكمبيوتر الذي تتم مراقبة موقعه.بمعنى آخر، لا يقوم FSW باختبار اتصال نظام التشغيل المتصل بالشبكة للتحقق من الملف.

قد يتصور المرء أن رسالة أو حدث فقط يتم رفعه/إرساله إلى FSW المتصل بالشبكة عند حدوث تغيير.

لكن هذا كله مجرد تكهنات.:)