additional-information
ERDDAP™- अपना खुद का सेट करेंERDDAP™
जो चीज़ें आपको जानना चाहिए
प्रॉक्सी त्रुटियां
कभी-कभी, अनुरोध करनाERDDAP™एक प्रॉक्सी त्रुटि, एक HTTP 502 बुरा गेटवे त्रुटि, या कुछ समान त्रुटि वापस कर देगा। इन त्रुटियों को अपाचे या टॉमकैट द्वारा फेंका जा रहा है, नहींERDDAP™खुद ही।
- यदि प्रत्येक अनुरोध इन त्रुटियों को उत्पन्न करता है, खासकर जब आप पहली बार अपनी स्थापना कर रहे हैंERDDAP™, तो यह शायद एक प्रॉक्सी या बुरा गेटवे त्रुटि ह ै, और समाधान शायद ठीक करने के लिए हैERDDAPप्रॉक्सी सेटिंग्स। यह भी समस्या हो सकती है जब एक स्थापितERDDAP™अचानक इन त्रुटियों को हर अनुरोध के लिए फेंकना शुरू हो जाता है।
- अन्यथा, "प्रोक्सी" त्रुटियां आमतौर पर वास्तव में अपाचे या टॉमकैट द्वारा फेंकी गई त्रुटियों को बाहर करती हैं। यहां तक कि जब वे अपेक्षाकृत जल्दी हो जाते हैं, तो यह अपाचे या टॉमकैट से कुछ प्रकार की प्रतिक्रिया है जो तब होती है जबERDDAP™बहुत व्यस्त, स्मृति-सीमित, या कुछ अन्य संसाधनों द्वारा सीमित है। इन मामलों में, के साथ सौदा करने के लिए नीचे सलाह देखेंERDDAP™धीरे जवाब देना।
एक लंबे समय सीमा के लिए अनुरोध (30 बार अंक) एक ग्रिड डेटासेट से समय-समय पर असफलता होती है, जो अक्सर प्रॉक्सी त्रुटियों के रूप में दिखाई देती है, क्योंकि यह महत्वपूर्ण समय लेता हैERDDAP™सभी डेटा फ़ाइलों को एक-एक करके खोलने के लिए। अगरERDDAP™अन्यथा अनुरोध के दौरान व्यस्त है, समस्या होने की संभावना अधिक है। यदि डेटासेट की फ़ाइलों को संकुचित किया जाता है, तो समस्या अधिक होने की संभावना है, हालांकि उपयोगकर्ता के लिए यह निर्धारित करना कठिन है कि डेटासेट की फ़ाइलों को संकुचित किया गया है या नहीं। समाधान कई अनुरोधों को बनाने के लिए है, प्रत्येक एक छोटी समय सीमा के साथ। कैसे एक समय सीमा के छोटे? मैं सुझाव देता हूं कि वास्तव में छोटा (~30 समय अंक?) फिर (लगभग) जब तक अनुरोध विफल हो जाता है तब तक डबल टाइम रेंज वापस आती है। फिर सभी अनुरोध करें (प्रत्येक समय के एक अलग हिस्से के लिए) सभी डेटा प्राप्त करने के लिए आवश्यक है। AnERDDAP™प्रशासक इस समस्या को कम कर सकता हैअपाचे टाइमआउट सेटिंग्स।
निगरानी
हम सभी चाहते हैं कि हमारी डेटा सेवाएँ अपने दर्शकों को ढूंढ सकें और बड़े पैमाने पर इस्तेमाल की जा सकें, लेकिन कभी-कभी आपकीERDDAP™बहुत ज्यादा इस्तेमाल किया जा सकता है, जिसमें सभी अनुरोधों के लिए सुपर धीमी प्रतिक्रियाएं शामिल हैं। समस्याओं से बचने की हमारी योजना है:
- मॉनिटरERDDAP™के माध्यम सेstatus.html वेब पेज। यह उपयोगी जानकारी के टन है। यदि आप देखते हैं कि अनुरोधों की एक बड़ी संख्या में आ रही है, या स्मृति के टन का इस्तेमाल किया जा रहा है, या असफल अनुरोधों के टन, या प्रत्येक मेजर लोडडाटासेट लंबे समय तक ले जा रहा है, या उन चीजों के किसी भी संकेत को देख सकते हैं जो धीरे-धीरे खराब हो रही हैं और जवाब दे रहे हैं, फिर देखोERDDAP'log.txt फ़ाइलयह देखने के लिए कि क्या चल रहा है।
यह भी ध्यान देने के लिए उपयोगी है कि स्टेटस पेज कितनी तेजी से जवाब देता है। यदि यह धीरे-धीरे जवाब देता है, तो यह एक महत्वपूर्ण सूचक है किERDDAP™बहुत व्यस्त है।
- मॉनिटरERDDAP™के माध्यम सेदैनिक रिपोर्टईमेल
- आउट-ऑफ-डेट डेटासेट के माध्यम से देखें बेस /erddap/outOfDateDatasets.htmlवेब पेज जो वैकल्पिक पर आधारित हैtestOutOfDateवैश्विक विशेषता।
बाह्य मॉनिटर
ऊपर सूचीबद्ध तरीके हैंERDDAPखुद की निगरानी के तरीके अपनी निगरानी के लिए बाह्य प्रणालियों को बनाने या उपयोग करना भी संभव हैERDDAP। यह करने के लिए एक परियोजना हैAxiom's erddap-metrics project। इस तरह के बाह्य प्रणालियों के कुछ फायदे हैं:
- उन्हें इच्छित जानकारी प्रदान करने के लिए अनुकूलित किया जा सकता है, जिसे आप चाहते हैं।
- वे जानकारी के बारे में शामिल कर सकते हैंERDDAP™किERDDAP™आसानी से उपयोग नहीं कर सकते (उदाहरण के लिए, सीपीयू उपयोग, डिस्क मुक्त स्थान,)ERDDAP™प्रतिक्रिया समय जैसा कि उपयोगकर्ता के दृष्टिकोण से देखा गया है,ERDDAP™अपटाइम,
- वे अलर्ट प्रदान कर सकते हैं (ईमेल, फोन कॉल, टेक्स्ट) जब समस्या कुछ सीमा से अधिक हो जाती है तो प्रशासकों को।
एक साथ अनुरोध
- ब्लैकलिस्ट उपयोगकर्ता एकाधिक एक साथ अनुरोध करते हैं! यदि यह स्पष्ट है कि कुछ उपयोगकर्ता एक से अधिक एक साथ अनुरोध कर रहा है, तो बार-बार और लगातार अपने आईपी पते को जोड़ने के लिएERDDAP[e]<अनुरोधब्लैकलिस्ट> (/docs/server-admin/datasets#requestblacklist) अपनेdatasets.xmlफ़ाइल कभी-कभी अनुरोध सभी एक आईपी पते से होते हैं। कभी-कभी वे एकाधिक आईपी पते से होते हैं, लेकिन स्पष्ट रूप से उसी उपयोगकर्ता। आप ब्लैकलिस्ट लोग भी कर सकते हैं जो टन अमान्य अनुरोधों या टन मानसिक रूप से अक्षम अनुरोधों को बनाते हैं।
फिर, प्रत्येक अनुरोध के लिए वे बनाते हैं,ERDDAP™रिटर्न:
HTTP ERROR 403 - Access Forbidden --
Your IP address is on this ERDDAP's request blacklist.
Did you often submit more than one request at a time?
Did you often submit identical requests in a short period of time?
Did you submit a large number of invalid requests?
If you are ready to avoid these problems, please email \[ERDDAP™ administrator's email address\] to request to be taken off of the blacklist.
उम्मीद है कि उपयोगकर्ता इस संदेश को देखेंगे और आपसे संपर्क करेगा कि समस्या को कैसे ठीक किया जाए और ब्लैकलिस्ट को कैसे बंद कर दिया जाए। कभी-कभी, वे सिर्फ आईपी पते स्विच करते हैं और फिर से कोशिश करते हैं।
यह युद्ध में आक्रामक और रक्षात्मक हथियारों के बीच शक्ति के संतुलन की तरह है। यहाँ, रक्षात्मक हथियार (ERDDAP) सीपीयू, डिस्क एक्सेस बैंडविड्थ और नेटवर्क बैंडविड्थ में कोर की संख्या तक सीमित एक निश्चित क्षमता है। लेकिन आक्रामक हथियार (उपयोगकर्ता, विशेष रूप से स्क्रिप्ट) असीमित क्षमता है:
- कई समय बिंदुओं से डेटा के लिए एक एकल अनुरोध का कारण हो सकता हैERDDAPफ़ाइलों की एक बड़ी संख्या खोलने के लिए (अनुक्रम में या आंशिक रूप से बहुधा) । अत्यधिक मामलों में, एक "सरल" अनुरोध आसानी से जुड़ा हुआ RAID को बांध सकता हैERDDAP™एक मिनट के लिए प्रभावी ढंग से अन्य अनुरोधों के संचालन को अवरुद्ध करता है।
- एक एकल अनुरोध स्मृति के एक बड़े हिस्से का उपभोग कर सकता है (हालांकिERDDAP™बड़े अनुरोधों को संभालने के लिए आवश्यक स्मृति को कम करने के लिए कोडित किया गया है) ।
- समानांतरकरण - यह एक चालाक उपयोगकर्ता के लिए बहुत सारे धागे पैदा करके एक बड़ा काम समानांतर करने के लिए आसान है, जिनमें से प्रत्येक एक अलग अनुरोध जमा करता है (जो बड़े या छोटे हो सकता है) । यह व्यवहार कंप्यूटर विज्ञान समुदाय द्वारा एक बड़ी समस्या से निपटने के लिए एक कुशल तरीका के रूप में प्रोत्साहित किया जाता है (और समानांतर अन्य परिस्थितियों में कुशल है) । वापस युद्ध के अनुरूप होने पर: उपयोगकर्ता अनिवार्य रूप से शून्य होने की लागत के साथ एक साथ अनुरोधों की अनिवार्य रूप से असीमित संख्या बना सकते हैं, लेकिन प्रत्येक अनुरोध की लागत में आने की लागतERDDAP™बड़ा हो सकता है औरERDDAPप्रतिक्रिया क्षमता सीमित है। स्पष्ट रूप से,ERDDAP™इस युद्ध को खो देंगे, जब तक कि यह युद्ध न हो जाएERDDAP™प्रशासक ब्लैकलिस्ट उपयोगकर्ता जो कई एक साथ अनुरोध कर रहे हैं जो अन्य उपयोगकर्ताओं को काफी हद तक भीड़भाड़ रहे हैं।
- एकाधिक स्क्रिप्ट - अब सोचें कि क्या होता है जब कई चालाक उपयोगकर्ता प्रत्येक समानांतर स्क्रिप्ट चल रहे हैं। यदि कोई उपयोगकर्ता इतना अनुरोध उत्पन्न कर सकता है कि अन्य उपयोगकर्ता भीड़-भाड़ रहे हैं, तो ऐसे कई उपयोगकर्ता इतने अनुरोध उत्पन्न कर सकते हैं किERDDAP™भारी हो जाता है और प्रतीत होता है कि unresponsive। यह प्रभावी रूप से एक हैडीडीओएस हमलाफिर, एकमात्र रक्षा के लिएERDDAP™ब्लैकलिस्ट उपयोगकर्ताओं को कई एक साथ अनुरोध करना है जो अन्य उपयोगकर्ताओं को काफी हद तक भीड़भाड़ रहा है।
- Inflated Expectations - इस दुनिया में बड़े पैमाने पर तकनीकी कंपनियों की दुनिया में (अमेज़न, गूगल, फेसबुक, ...) उपयोगकर्ता प्रदाताओं से अनिवार्य रूप से असीमित क्षमताओं की उम्मीद करते हैं। चूंकि ये कंपनियां धन निर्माण कार्य कर रही हैं, उनके पास जितना उपयोगकर्ता हैं, उतना ही राजस्व उन्हें अपने आईटी बुनियादी ढांचे का विस्तार करना पड़ता है। इसलिए वे अनुरोधों को संभालने के लिए एक विशाल IT अवसंरचना प्रदान कर सकते हैं। और वे उपयोगकर्ताओं से अनुरोधों की संख्या और प्रत्येक अनुरोध की लागत को सीमित करते हैं, उन अनुरोधों के प्रकार को सीमित करते हैं जो उपयोगकर्ता ऐसा कर सकते हैं कि कोई भी अनुरोध बोझिल नहीं है, और कोई कारण नहीं है (या एक रास्ता) उपयोगकर्ताओं के लिए एकाधिक एक साथ अनुरोध करने के लिए। तो इन विशाल तकनीकी कंपनियों की तुलना में कहीं अधिक उपयोगकर्ता हो सकता हैERDDAP™लेकिन उनके पास प्रत्येक उपयोगकर्ता के अनुरोध को सीमित करने के लिए बड़े पैमाने पर अधिक संसाधन और चालाक तरीके हैं। यह बड़ी आईटी कंपनियों के लिए एक प्रबंधनीय स्थिति है (और वे अमीर हो जाते हैं!) लेकिन नहींERDDAP™स्थापना। फिर, एकमात्र रक्षा के लिएERDDAP™ब्लैकलिस्ट उपयोगकर्ताओं को कई एक साथ अनुरोध करना है जो अन्य उपयोगकर्ताओं को काफी हद तक भीड़भाड़ रहा है।
इसलिए उपयोगकर्ता: एकाधिक एक साथ अनुरोध नहीं करते हैं या आप ब्लैकलिस्ट किए जाएंगे!
स्पष्ट रूप से, यह सबसे अच्छा है यदि आपके सर्वर में बहुत सारे कोर हैं, तो बहुत सारी मेमोरी (इसलिए आप स्मृति के बहुत सारे आवंटित कर सकते हैंERDDAP™कभी जरूरत से अधिक) , और एक उच्च बैंडविड्थ इंटरनेट कनेक्शन। फिर स्मृति शायद ही कभी या कभी सीमित कारक नहीं है, लेकिन नेटवर्क बैंडविड्थ अधिक आम सीमित कारक बन जाता है। मूल रूप से, जैसा कि अधिक से अधिक एक साथ अनुरोध हैं, किसी भी उपयोगकर्ता को गति कम हो जाती है। यह स्वाभाविक रूप से उन अनुरोधों की संख्या को धीमा कर देता है जिनमें प्रत्येक उपयोगकर्ता सिर्फ एक बार में एक अनुरोध जमा कर रहा है।