सिस्टम -IO.FileSystemWatcher नेटवर्क-सर्वर फ़ोल्डर की निगरानी करने के लिए - प्रदर्शन विचार

Question

मैं परिवर्तन के लिए नेटवर्क सर्वर पर एक फ़ोल्डर पेड़ देखना चाहता हूं। फाइलों में एक विशिष्ट एक्सटेंशन है। पेड़ में लगभग 200 फ़ोल्डर्स और विस्तार के साथ लगभग 1200 फाइलें हैं जिन्हें मैं देख रहा हूं।

मैं सर्वर (ऑफ-सीमा!) पर चलाने के लिए एक सेवा नहीं लिख सकता, इसलिए समाधान क्लाइंट के लिए स्थानीय होना चाहिए। समयबद्धता विशेष रूप से महत्वपूर्ण नहीं है। मैं अधिसूचनाओं में एक मिनट या अधिक देरी के साथ रह सकता हूं। मैं बनाएँ, हटाएं, नाम बदलें और परिवर्तन के लिए देख रहा हूं।

.NET System.IO.fileSystemWatcher का उपयोग सर्वर पर अधिक लोड बनायेगा?

10 अलग-अलग दर्शक कैसे देखे जा रहे फ़ोल्डरों/फ़ाइलों की संख्या को कम करने के लिए? (700 फ़ोल्डर्स से 200 तक, कुल में 5500 फाइलों से 1200) कम नेटवर्क ट्रैफिक कम के बजाय? मेरे विचार 1 पेड़ के नीचे देखे गए फाइलों को रखने के लिए सर्वर पर एक reshuffle हैं। मेरे पास हमेशा इस विकल्प नहीं है इसलिए दर्शक की टीम।

मुझे लगता है कि अन्य समाधान एक आवधिक जांच है यदि FSW सर्वर पर एक अनुचित लोड बनाता है, या यदि यह SysAdmin प्रकार के कारणों के पूरे समूह के लिए काम नहीं करता है।

क्या ऐसा करने का कोई बेहतर तरीका है?

Answer 1

एक सर्वर लोड बिंदु दृश्य से, IO.FileSystemWatcher का उपयोग करके परिदृश्य में रिमोट चेंज नोटिफिकेशन के लिए आप संभवतः सबसे कुशल विधि संभव है। यह FindFirstChangeNotification और ReadDirectoryChangesW आंतरिक रूप से Win32 एपीआई फ़ंक्शंस का उपयोग करता है, जो बदले में नेटवर्क रीडायरेक्टर के साथ एक अनुकूलित तरीके से संवाद करता है (मानक विंडोज नेटवर्किंग मानते हैं: यदि कोई तृतीय-पक्ष रीडायरेक्टर उपयोग किया जाता है, और यह आवश्यक कार्यक्षमता का समर्थन नहीं करता है, तो चीजें जीती जाती हैं बिल्कुल काम नहीं करते हैं)। .NET wrapper भी अधिकतम दक्षता सुनिश्चित करने के लिए async I/O और सबकुछ का उपयोग करता है।

इस समाधान के साथ एकमात्र समस्या यह है कि यह बहुत विश्वसनीय नहीं है। अस्थायी रूप से दूर जाने वाले नेटवर्क कनेक्शन से निपटने के अलावा (जो कि समस्या का बहुत अधिक नहीं है, क्योंकि IO.FileSystemWatcher इस मामले में एक त्रुटि घटना को आग लगाएगा जिसे आप संभाल सकते हैं), अंतर्निहित तंत्र में कुछ मौलिक सीमाएं हैं।Win32 एपीआई कार्यों के लिए MSDN प्रलेखीकरण से:

• ReadDirectoryChangesW ERROR_INVALID_PARAMETER के साथ विफल बफर लंबाई से अधिक 64 KB है और आवेदन नेटवर्क पर एक निर्देशिका की निगरानी कर रहा हो। यह अंतर्निहित फ़ाइल साझा प्रोटोकॉल

• सूचनाएं एक दूरस्थ फाइल सिस्टम

दूसरे शब्दों में के लिए FindFirstChangeNotification बुला वापस नहीं किया जा सकता है के साथ एक पैकेट आकार सीमा के कारण है: अत्यधिक भार (जब तुम करोगी एक बड़े बफर की आवश्यकता है) या, बदतर, यादृच्छिक अनिर्दिष्ट परिस्थितियों में, आपको उन अधिसूचनाएं प्राप्त नहीं हो सकती हैं जिन्हें आप उम्मीद करते हैं। स्थानीय फाइल सिस्टम वॉचर्स के साथ यह भी एक मुद्दा है, लेकिन नेटवर्क पर यह एक समस्या है। Another question here on SO एपीआई के साथ अंतर्निहित विश्वसनीयता समस्याओं का विवरण थोड़ा अधिक विस्तार से करता है।

फ़ाइल सिस्टम वॉचर्स का उपयोग करते समय, आपका आवेदन इन सीमाओं से निपटने में सक्षम होना चाहिए। उदाहरण के लिए:

• फ़ाइलें आप देख रहे हैं अनुक्रम नंबर हैं, तो, पिछले क्रम संख्या के बारे में सूचित किया गया स्टोर ताकि आप भविष्य सूचनाओं पर 'अंतराल' के लिए देखो और जिसके लिए फ़ाइलों को प्रोसेस कर सकते हैं अधिसूचित नहीं किया गया;

• अधिसूचना प्राप्त करने पर, हमेशा एक पूर्ण निर्देशिका स्कैन करें। यह वास्तव में खराब लग सकता है, लेकिन चूंकि स्कैन घटना संचालित है, यह अभी भी गूंगा मतदान से कहीं अधिक कुशल है। साथ ही, जब तक आप एक निर्देशिका में फ़ाइलों की कुल संख्या रखते हैं, साथ ही निर्देशिकाओं की संख्या स्कैन करने के लिए, हजारों या उससे भी कम के तहत, प्रदर्शन पर इस ऑपरेशन का प्रभाव वैसे भी बहुत कम होना चाहिए।

कई श्रोताओं सेट करने से आप जितना संभव हो उतना से बचना चाहिए कुछ है: अगर कुछ भी, यह बातें कर देगा भी कम विश्वसनीय ...

वैसे भी, अगर आप पूरी तरह है उपयोग करने के लिए फ़ाइल सिस्टम वॉचर्स, जब तक आप सीमाओं से अवगत हैं, तब तक चीजें ठीक से काम कर सकती हैं, और संशोधित/बनाई गई प्रत्येक फ़ाइल के लिए 1: 1 अधिसूचना की अपेक्षा नहीं करते हैं।

तो, यदि आपके पास अन्य विकल्प हैं (अनिवार्य रूप से, फ़ाइलों को लिखने की प्रक्रिया होने से आपको गैर-फाइल सिस्टम आधारित तरीके से सूचित किया जाता है: कोई नियमित आरपीसी विधि एक सुधार होगा ...), वे निश्चित रूप से देखने योग्य हैं एक विश्वसनीयता बिंदु से।

Answer 2

मुझे नहीं लगता कि कंप्यूटर के बीच एफएसडब्ल्यू और कंप्यूटर के बीच किसी भी तरह का सक्रिय राज्य या संचार है जिसका स्थान पर नजर रखी जा रही है। दूसरे शब्दों में, एफएसडब्ल्यू फाइल को जांचने के लिए नेटवर्क ओएस को पिंग नहीं कर रहा है।

कोई कल्पना करेगा कि एक संदेश या घटना केवल परिवर्तन होने पर नेटवर्क किए गए FSW को उठाया/भेजा गया है।

लेकिन यह सब सिर्फ अटकलें हैं। :)

Answer 3

MSDN documentation indicates कि आप फ़ाइल पर सिस्टम सिस्टम परिवर्तनों को देखने के लिए FileSystemWatcher घटक का उपयोग कर सकते हैं ड्राइव।

यह भी इंगित करता है कि वॉचर घटक समय-समय पर परिवर्तन के लिए लक्ष्य ड्राइव की पूछताछ के बजाय फ़ाइल सिस्टम परिवर्तन अधिसूचनाओं के लिए सुनता है।

उस पर निर्भर करता है कि नेटवर्क यातायात की मात्रा पूरी तरह से निर्भर करती है कि आप उस नेटवर्क ड्राइव की सामग्री को कितनी अपेक्षा करते हैं। एफएसडब्ल्यू घटक नेटवर्क यातायात के स्तर में नहीं जोड़ा जाएगा।

Answer 4

मैंने फ़ाइल सिस्टम वॉचर्स को कई बार सी # से उपयोग किया है। पहली बार मैंने उन्हें इस्तेमाल किया, मुझे उनके साथ काम करने से रोकने में समस्याएं थीं, मुख्य रूप से इस तथ्य के कारण कि मैं परिवर्तन की सूचना देने वाले धागे में हुए बदलावों को संसाधित कर रहा था।

हालांकि, मैं सिर्फ एक कतार में परिवर्तन को धक्का देता हूं और कतार को किसी अन्य थ्रेड पर संसाधित करता हूं। ऐसा लगता है कि मूल रूप से मेरी समस्या का समाधान हुआ। आपकी समस्या के लिए, आप एक ही कतार पर धक्का देने वाले कई दर्शक देख सकते हैं।

हालांकि, मैंने इसका उपयोग आपके प्रकार की समस्या के साथ नहीं किया है।

Answer 5

मेरे अनुभव में, एक एफएसडब्ल्यू उच्च नेटवर्क यातायात नहीं बनाता है। हालांकि, यदि कोई प्रदर्शन समस्या है, तो कई वॉचर्स का उपयोग करने और कम फ़ोल्डरों को इसे तोड़ने के आपके दृष्टिकोण को उचित लगता है।

मुझे नेटवर्क ड्राइव पर एफएसडब्ल्यू के साथ कुछ बड़ी समस्याएं थीं, हालांकि: फ़ाइल को हटाने से हमेशा त्रुटि घटना फेंक दी गई, कभी भी हटाई गई घटना नहीं हुई। मुझे कोई समाधान नहीं मिला, इसलिए अब मैं एफएसडब्ल्यू का उपयोग करने से बचता हूं यदि इसके आसपास कोई रास्ता है ...

Answer 6

वॉचर 100% विश्वसनीय दिखता है - केवल वॉचर ऑब्जेक्ट पर बफर आकार देखें। मैंने हजारों फाइल-अपडेट का परीक्षण किया है, कोई भी खो गया नहीं है।

मैं एक बहु थ्रेडेड दृष्टिकोण का उपयोग करने की सलाह देता हूं - ट्रिगर फ़ाइल वॉचर है। यह प्रत्येक फ़ाइल-परिवर्तन के लिए एक धागा लॉन्च कर सकता है। वॉचर ओवरफ़्लो के कम अवसर के साथ को बहुत तेजी से संसाधित कर सकता है। (Async थ्रेड का उपयोग करें)

Answer 7

कुछ समय के लिए System.IO.FileSystemWatcher का उपयोग करने के बाद। यह बहुत तेजी से आने वाली घटनाओं को संभालने के लिए पर्याप्त स्थिर नहीं है। फ़ाइलों का 100% पढ़ने के लिए सुनिश्चित करने के लिए। मैं फ़ाइलों के माध्यम से खोजने के लिए सरल निर्देशिका विधियों का उपयोग करता हूं। इसे पढ़ने के बाद, फ़ाइलों को तुरंत किसी अन्य फ़ोल्डर में कॉपी करें। फ़ाइलों को पढ़ते समय इसे नई फाइलों से जोड़ने के लिए अलग करें।

टाइमर नियमित रूप से फ़ोल्डर को पढ़ने के लिए उपयोग किया जाता है। संग्रहीत फ़ोल्डर में पहले से पढ़ी गई फ़ाइल की प्रतिलिपि बनाकर, यह सुनिश्चित करें कि इसे दोबारा नहीं पढ़ा जाएगा। बाद में पढ़ना हमेशा नई फाइलें होगी।

var fileNames = Directory.GetFiles (srcFolder); foreach (फ़ाइल नामों में स्ट्रिंग फ़ाइल नाम) { स्ट्रिंग [] लाइनें = फ़ाइल। रीडअललाइन (फ़ाइल नाम);