उल्का की सदस्यता और सिंक धीमी हैं

Question

मेरे पास 6000 शेयरों के 10 एम दस्तावेज़ों के साथ एक संग्रह है, स्टॉक नाम अनुक्रमित है। जब मैं एक नए स्टॉक की सदस्यता लेता हूं, तो इस स्टॉक के 3000 दस्तावेज प्राप्त करने के लिए उल्का 10 सेकंड से अधिक लटकता है। इसके अलावा कई स्टॉक सब्सक्राइब किए जाने के बाद, उल्का 100% सीपीयू उपयोग के साथ लटकता है। उल्का "बड़ा" संग्रह समन्वयित करने के साथ वास्तव में धीमा दिखता है। दरअसल मेरा ऐप सिर्फ पढ़ता है। मैं सोच रहा हूं कि रीड-ओनली क्लाइंट के लिए उल्का तेज करने का कोई तरीका है या नहीं? मैं यह भी सोच रहा हूं कि प्रत्येक स्टॉक के लिए एक अलग संग्रह बनाने में मदद मिलती है?

Answer 1

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

पूरे उल्का ढेर किसी भी देशी ढेर में एक साधारण कार्यान्वयन पर चरम ओवरहेड पेश करता है; ईमानदारी से, मैं यह भी ध्यान में रखता हूं कि ओवरहेड जावा या सी # उस और निम्न स्तर की भाषाओं जैसे PHP और सी ++ के बीच चयन करते समय दो बार सोचेंगे और सोचेंगे। रूबी, पायथन, नोड.जेएस और अधिक जैसी भाषाएं वास्तव में एक अलग कहानी हैं; वे तेजी से प्रोटोटाइप के लिए बने होते हैं लेकिन विलंबता/थ्रूपुट के मामले में वे ओवरहेड के कारण पीछे होते हैं, जो उन्हें जेआईटी ले जाता है, चीजों को जोड़ने के लिए कुछ गैर-मूल दृष्टिकोणों को ओवरहेड पर नहीं भूलना।

टी एल; डॉ: उपयोग इस काम के लिए सही उपकरण, या आप अपनी उंगलियों को काट देंगे ...

Answer 2

मैं उल्का के सादगी से प्यार है। सिंक के ओवरहेड से बचने के लिए मैं बस स्थानीय मोंगोडब संग्रह का उपयोग करना बंद कर देता हूं, प्रदर्शन वास्तव में अच्छा लगता है।

Meteor.default_connection.registerStore "prices", 
    beginUpdate: -> 
    update: (msg) -> 
    updateChart(msg.set) 
    endUpdate: -> 
    reset: -> 

नए उल्का के लिए, नीचे काम करता है।

Meteor.default_connection.registerStore collection, 
    constructor: (@update) -> 
    # Called at the beginning of a batch of updates. 
    beginUpdate: -> 
    update: (msg) -> 
     update(msg.fields, msg.id) if msg.fields 
    endUpdate: -> 
    reset: -> 

Answer 3

उल्का पूरे डेटासेट को आपके क्लाइंट को दबा रहा है।

आप autopublish पैकेज को हटाने के द्वारा autopublish बंद कर सकते हैं:

meteor remove autopublish

फिर अपने ग्राहक के लिए विशिष्ट किसी विशिष्ट सदस्यता पैदा करते हैं।

जब आप सदस्यता ले आप, एक तर्क के रूप में एक सत्र चर पारित कर सकते हैं ताकि ग्राहक पर आप की तरह कुछ कार्य करें:

sub = new Meteor.autosubscribe(function(){ Meteor.subscribe('channelname', getSession('filterval')); }

सर्वर आप तर्क का उपयोग फिल्टर करने के लिए परिणाम के लिए भेजा सेट पर ग्राहक, ताकि आप सब कुछ एक साथ में पाइप नहीं कर रहे हैं। आप फिल्टर का उपयोग कर कुछ फैशन में डेटा को विभाजित करते हैं।

Meteor.publish('channelname', function(filter){ return Collection.find({field: filter}); }

अब, जब भी आप ग्राहक setSession('filterval', 'newvalue'); सदस्यता के प्रयोग पर filterval बदल स्वचालित रूप से बदल जाएगा, और नए डाटासेट ग्राहक को भेजा जाएगा।

आप इसे नियंत्रित करने के साधन के रूप में उपयोग कर सकते हैं कि ग्राहक को कितना डेटा भेजा जाता है।

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

किसी अन्य उपयोग के मामले (जैसे केवल पढ़ने के लिए विशाल डेटासेट) के लिए यह समझ में नहीं आता है। इसमें बहुत अधिक ओवरहेड है जो कार्यक्षमता प्रदान करता है जिसका आप उपयोग नहीं करेंगे, और आप जिस कार्यक्षमता की आवश्यकता है उसे प्राप्त करने के लिए आप कोडिंग करेंगे।

Answer 4

स्वत: प्रकाशित करने के साथ आप Mongodb में दस्तावेज़ों के बड़े संग्रह के साथ एक प्रदर्शन हिट देख सकते हैं। आप ऑटोपublलिश को हटाकर और संपूर्ण डेटाबेस के बजाय प्रासंगिक डेटा को प्रकाशित करने के लिए कोड लिखकर इसे संबोधित कर सकते हैं।

डॉक्स मैन्युअल रूप से भी कैश प्रबंध में जाने:

आधुनिकतम ग्राहकों से सदस्यता बंद कर सकते हैं और बंद कैसे ज्यादा डेटा कैश में रखा जाता है को नियंत्रित करने और नेटवर्क यातायात का प्रबंधन करने के। जब सदस्यता बंद हो जाती है, तो उसके सभी दस्तावेज़ कैश से हटा दिए जाते हैं जब तक कि वही दस्तावेज़ किसी अन्य सक्रिय सदस्यता द्वारा प्रदान नहीं किया जाता है।

वर्तमान में उल्का में अतिरिक्त प्रदर्शन सुधारों पर काम किया जा रहा है, जिसमें "बहुत बड़ी संख्या में ग्राहकों" का समर्थन करने के लिए डीडीपी-स्तर प्रॉक्सी शामिल है। आप उल्का roadmap पर इस पर अधिक जानकारी देख सकते हैं।

Answer 5

मैं एक ही मुद्दे से जूझ रहा था। मेरे मामले में मुझे केवल 3000 केबी रिकॉर्ड के आसपास ~ 3000 रिकॉर्ड सिंक करना पड़ा। कोशिश करने के हफ्तों के बाद मुझे अंततः एहसास हुआ कि सिंक मुद्दा नहीं था, लेकिन लगता है कि सिंक्रनाइज़ेशन के दौरान हुआ लाइव HTML अपडेट।

मैं प्रारंभिक पृष्ठ लोड के दौरान टेम्पलेट अपडेट अक्षम करके सभी 3000 रिकॉर्ड के लिए 300 सेकंड (फ़िल्टर किए गए) रिकॉर्ड के लिए 10 सेकंड से कम समय तक अपने पृष्ठ लोड को कम करने में सक्षम था। मैं पूरा किया कि समारोह है कि टेम्पलेट सामग्री परिभाषित करने के लिए एक शर्त जोड़कर:

से पहले (300 रिकॉर्ड के लिए 10s पृष्ठ लोड सर्वर द्वारा प्रकाशित किया जा रहा): 3000 के रिकॉर्ड के लिए

Template.itemlist.items = function() { 
    return Item.find({type: 'car'}, 
        {sort: {start: -1}, 
         limit: 30}); 
}; 

करने के लिए (2s पृष्ठ लोड सर्वर द्वारा प्रकाशित):

Template.itemlist.items = function() { 
    if (Session.get("active")) {  
     return Item.find({type: 'car'}, 
         {sort: {start: -1}, 
          limit: 30}); 
    } else { 
     return []; 
    } 
}; 

"को सक्रिय" करने के लिए सत्र केवल एक बार डेटा लोड किया गया था, मैं कहा:

Deps.autorun(function() { 
    Meteor.subscribe("Item", 
        { 
         onReady: function() { 
          Session.set("active", true); 
         } 
        }); 
});