उल्लू को देखते हुए उल्का/मोंगो में इतना समय क्यों लगता है?

Question

मेरे पास एक मोंगोलाब क्लस्टर है, जो मुझे मेरे Meteor.js ऐप में प्रदर्शन, उपलब्धता और अनावश्यकता को बेहतर बनाने के लिए ओप्लॉग पूंछ का उपयोग करने की अनुमति देता है।

समस्या यह है: चूंकि मैं इसका उपयोग कर रहा हूं, मेरे सभी प्रकाशनों को समाप्त करने में अधिक समय लगता है। जब यह केवल 200ms की तरह लेता है, यह कोई समस्या नहीं है, लेकिन यह अक्सर अधिक पसंद करता है, जैसे कि मैं प्रकाशन के लिए सदस्यता ले रहा हूं, मैंने here का वर्णन किया है।

इस प्रकाशन में पहले से ही बहुत लंबा प्रतिक्रिया समय है, और ओप्लॉग अवलोकन भी धीमा कर रहे हैं, हालांकि यह एकमात्र प्रकाशन होने से बहुत दूर है जहां ओप्लोग को देखते हुए इतना समय लगता है।

क्या कोई मुझे बता सकता है कि क्या हो रहा है? कहीं भी जहां मैं वेब पर खोज करता हूं, मुझे इस बारे में कोई स्पष्टीकरण मिलता है कि क्यों ओप्लोग को मेरे प्रकाशन को धीमा करना है।

और अंत में, एक:

यहाँ एक और पब/उप से एक स्क्रीनशॉट है:

यहाँ वर्णन करने के लिए कि मैं क्या कह रहा हूँ Kadira से कुछ स्क्रीनशॉट हैं जहां oplogs को उचित समय लगता है (लेकिन फिर भी मेरा पब/सब थोड़ा धीमा):

Answer 1

ओप्लॉग पूंछ बहुत तेज़ है। ओप्लॉग पूंछ यहां मुद्दा नहीं है।

आप शायद बहुत कुछ है कि आप प्रकाशनों की गति कम कर एहसास नहीं है कर रहे हैं:

• एक-एक करके अद्यतन के बाद दस्तावेज़ लूप: आप शायद एक दस्तावेज़ अद्यतन कर रहे हैं Collection.forEach कॉल के शरीर के अंदर। यह अविश्वसनीय रूप से धीमा है, और विधि निकायों में आपके खराब प्रदर्शन की उत्पत्ति है। हर बार जब आप एक ही दस्तावेज़ अपडेट करते हैं जो सैकड़ों समवर्ती कनेक्शनों द्वारा सुना जाता है, उनमें से प्रत्येक को अद्यतन करने की आवश्यकता होती है; एक बार एक अपडेट के बाद एक प्रश्न करके, न तो मोंगो और न ही मेटियर अनुकूलित कर सकते हैं और उन्हें हर बदलाव पर प्रत्येक उपयोगकर्ता को अपडेट होने की प्रतीक्षा करनी होगी। यह आपके प्रदर्शन में दोगुनी-एसिम्प्टोटिक वृद्धि है। समाधान: {multi:true} का उपयोग कर अद्यतन कैसे करें के बारे में सोचें।
• प्रत्येक उपयोगकर्ता के लिए अद्वितीय प्रश्न: यदि आप उपयोगकर्ता दस्तावेज़ में एक ही बदलाव करते हैं, तो इसके साथ जुड़े 100 समवर्ती अद्वितीय सदस्यता, कनेक्शन को क्रमशः अधिसूचित किया जाएगा। इसका मतलब है कि पहला कनेक्शन 90 एमएमएस में अधिसूचित किया जाएगा, जबकि अंतिम कनेक्शन 90 एमएमएस * 100 उपयोगकर्ताओं के बाद अधिसूचित किया जाएगा। यही कारण है कि आपके observeChanges धीमे हैं। समाधान: इस बारे में सोचें कि आपको वास्तव में प्रत्येक उपयोगकर्ता दस्तावेज़ पर एक अद्वितीय सदस्यता की आवश्यकता है या नहीं। उल्का में एकाधिक समवर्ती संग्रहों के बीच साझा समान सदस्यता के अनुकूलन हैं।
• बहुत सारे दस्तावेज़: आप शायद प्रत्येक थ्रेड टिप्पणी, पोस्ट, चैट संदेश इत्यादि को अपने दस्तावेज़ के रूप में एन्कोड कर रहे हैं। प्रत्येक दस्तावेज़ को प्रत्येक क्लाइंट को व्यक्तिगत रूप से भेजा जाना चाहिए, कुछ संबंधित ओवरहेड पेश करना। यह एक रिलेशनल डेटाबेस के लिए सही स्कीमा है, और दस्तावेज़-आधारित डेटाबेस के लिए गलत है।समाधान: किसी भी दस्तावेज़ को किसी दस्तावेज़ में एक पृष्ठ (डी-सामान्यीकरण) में प्रस्तुत करने के लिए आपको आवश्यक प्रत्येक चीज़ को पकड़ने का प्रयास करें। चैट के संबंध में, आपके पास एक "वार्तालाप" दस्तावेज़ होना चाहिए जिसमें दो + उपयोगकर्ताओं के बीच सभी संदेश शामिल हों।
• डेटाबेस आपके होस्ट के साथ सह-स्थित नहीं है: यदि आप मोंगोलाब का उपयोग कर रहे हैं, तो आपका डेटाबेस आपके वेब होस्ट (जिसे मैं गैलेक्सी या मॉड्यूलस मानता हूं) के समान डेटासेंटर में नहीं हो सकता है। इंट्रा-डेटासेंटर विलंबता बहुत अधिक हो सकती है, और शायद यह आपके खराब संग्रह को पढ़ने के लिए स्पष्टीकरण है। सूचकांक, जैसा कि अन्य टिप्पणीकारों ने देखा है, एक भूमिका निभा सकते हैं, लेकिन मेरी शर्त यह है कि इनमें से किसी भी संग्रह में आपके पास सौ से कम रिकॉर्ड हैं, इसलिए इससे कोई फर्क नहीं पड़ता।