पृष्ठभूमि में एकाधिक असीमित अनुरोधों के कारण विलंबता के विरुद्ध वेब आधारित एप्लिकेशन को अनुकूलित कैसे करें?

Question

मैं पतली सर्वर क्लाइंट साइड एमवीसी आर्किटेक्चर के आधार पर एक मॉड्यूलर आरआईए डिजाइन कर रहा हूं। अभी, आवेदन केवल 10% की सीमा तक पूरा है और इस तरह डिज़ाइन परिवर्तनों को शामिल करने में बहुत देर हो चुकी है।

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

हालांकि मुझे इसके बारे में चिंता है कि, क्या यह संभव है कि पृष्ठभूमि में चल रहे कई डेटा भारी AJAX अनुरोध ब्राउज़र को रोक दें? मैंने हाल ही में कुछ सामाजिक सामग्री एकत्रीकरण सेवाओं में कुछ गंभीर विलंबता समस्याओं को देखा है और क्लाइंट साइड कोड का विश्लेषण करने पर मुझे आश्चर्य हुआ कि क्लाइंट पक्ष का आवेदन पदचिह्न 300KB के भीतर काफी छोटा था। हालांकि, एप्लिकेशन को चलाने पर अक्सर ब्राउज़र (फ़ायरफ़ॉक्स और आईई दोनों) फांसी लगाई और ठीक होने में कई सेकंड लग गए। एस्क्रोनस अनुरोधों का विश्लेषण करने पर यह प्रतीत होता है कि एप्लिकेशन जीमेल, फेसबुक और ट्विटर से उपयोगकर्ता सामग्री को एक साथ ला रहा था और उन्हें डीओएम में धक्का दे रहा था और बहुत अधिक मेमोरी संसाधन ले रहा था।

यह अच्छा होगा अगर कोई मुझे ऐसे मुद्दों को रोकने के लिए कुछ दिशानिर्देश/सर्वोत्तम प्रथाओं को इंगित कर सकता है। क्या एक कस्टम रैपर स्क्रिप्ट लिखने की सलाह दी जाएगी जो पृष्ठभूमि में सामग्री को क्रमशः समान रूप से लोड करने के बजाय महत्व के पूर्व-निर्दिष्ट क्रम में लोड करता है, जिसके परिणामस्वरुप कई कॉलबैक समानांतर में निष्पादित हो सकते हैं।

किसी भी सलाह की सराहना की जाएगी।

Answer 1

एक समाधान, अच्छी तरह से यह सभी मामलों के लिए हत्यारा समाधान नहीं है, लेकिन एक समाधान सर्वर पक्ष पर सामग्री एकत्रीकरण को प्रस्तुत करना है और सभी अंतिम ब्राउज़र में नहीं।

यह ESIGates के साथ किया जा सकता है। उनमें से एक Varnish-Esi है, लेकिन इसमें पूरे ESI specification शामिल नहीं हैं। This one (esigate.org) भी ओपन सोर्स है और शायद बेहतर कवरेज के साथ (अभी तक परीक्षण नहीं किया गया है)। ईएसआई सिस्टम का मतलब है कि आपका एप्लिकेशन लेआउट विभिन्न कैश नीति (टीटीएल), और विभिन्न प्रदाताओं के साथ विभिन्न ब्लॉक का संयोजन हो सकता है। ईएसआई सर्वर उस ट्रैफ़िक का एक हिस्सा लेगा जिसे आपने प्रारंभ में अंतिम ब्राउज़र में भेज दिया था, इसलिए यह आपको बहुत अधिक बैंडविड्थ खर्च करेगा, लेकिन कम से कम आपको अधिक नियंत्रण सॉफ़्टवेयर के इस टुकड़े पर मिलेगा HTTP क्लाइंट्स द्वारा उपयोग किए जाने वाले विभिन्न ब्राउज़र।

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

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

मुझे लगता है कि आपका एप्लिकेशन एक छोटा-स्थैतिक अनुप्रयोग है जो असीमित रूप से लोड किए गए डेटा के साथ है, आप बहुत सारे AJAX का उपयोग कर रहे हैं और बहुत अधिक पृष्ठ परिवर्तन नहीं कर रहे हैं। इसका मतलब है कि एक बार सामग्री लोड होने के बाद यह लंबे समय तक पृष्ठ में रह जाएगी।

तो सामाजिक-नेटवर्क होने & अन्य वेब सेवाओं सामग्री देरी और श्रृंखलित एक बड़ा समानांतर लोड के बजाय एक समस्या हो should'nt। हो सकता है कि यह पहले 15 के दशक में नहीं होगा, लेकिन अगर यह अगले 15 मिनट के लिए पेज पर रहता है तो शायद यह कोई समस्या नहीं है (यदि सबसे महत्वपूर्ण सामग्री पहले से मौजूद है तो उपयोगकर्ता शायद यह भी ध्यान न दे कि सजावटी सामग्री उपलब्ध नहीं था)। यहां एक आईई 6 (और कभी-कभी आईई 7) टिप, पेजों के पुनर्निर्मित करने के लिए हर जगह SetTimeouts() जेएस कमांड का उपयोग करें, आप देखेंगे कि उपलब्ध सामग्री तेजी से दिखाई देती है।

अंतिम युक्ति, यदि आपको अद्यतन सामग्री के लिए कुछ नियमित AJAX चेक बनाने की आवश्यकता है। यदि आप वास्तव में हर मिनट 10 सामग्री के लिए जांच करते हैं तो आपको हमेशा समानांतर लोड समस्याएं और एक बड़ी गतिविधि मिलती है, प्रारंभिक लोड में समान समस्या, आमतौर पर आप उस समस्या को ठीक करने के लिए 2 चीजों का उपयोग कर सकते हैं, एक COMET familly long -उत्पादित HTTP कनेक्शन (इसलिए आप पुश डेटा और/या तेजी से प्रतिक्रिया प्राप्त कर सकते हैं, लेकिन केवल आपके सर्वर के साथ उस प्रकार के HTTP ट्रैफ़िक के लिए ट्यून किया गया है)। दूसरा चेक समय कारक अगले चेक के लिए जोड़ रहा है, ताकि पहली जांच 1 मिनट के बाद हो, अगले 2minutes, फिर 3, 15, 25, आदि, अंत में आपके पास केवल एक घंटे की जांच हो शायद। और जब आप उपयोगकर्ता से कुछ गतिविधि (कुछ उपयोगकर्ता इंटरैक्शन) का पता लगाते हैं तो आप अगली चेक विलंबता को कम कर सकते हैं। ऐसा इसलिए है क्योंकि आप यह मान सकते हैं कि उपयोगकर्ता वास्तव में केवल तभी ताजा डेटा ढूंढ रहा है जब वह वास्तव में आपके पृष्ठ के साथ कुछ कर रहा हो। आप कुछ उपयोगकर्ता सीपीयू को बचाएंगे, और आप अपने सर्वर लोड में भी मदद करेंगे।

Answer 2

मेरे पास फेसबुक/लिंक्ड आईडी/आदि प्लगइन की वजह से पेज लोडिंग देरी भी थी।

मेरे लिए समाधान तीसरे पक्ष की जावास्क्रिप्ट की असीमित लोडिंग है। यह हर वेब सेवा/विजेट के लिए काम नहीं करता है, लेकिन उनमें से कई (फेसबुक "पसंद" बटन, ट्विटर "ट्वीट" बटन इत्यादि के लिए काम करता है)।

उदाहरण:

<div id="tweet"> 
    <a href="http://twitter.com/share" 
     class="twitter-share-button" 
     data-count="horizontal" 
    >Tweet</a> 
</div> 
<script type="text/javascript"> 
    $(function() { 
     $.getScript('http://platform.twitter.com/widgets.js'); 
    }); 
</script> 

इस कोड के बाद पृष्ठ (DOM) "ट्वीट" बटन प्रस्तुत करना होगा लोड।

लेकिन अगर आपको अनुरोध है कि वेब-सेवा की जावास्क्रिप्ट दस्तावेज़.write() या नहीं है तो आपको पहले जांच करनी चाहिए। यदि ऐसा होता है - आप यहां कुछ भी नहीं कर सकते हैं, केवल सिंक लोड संभव है।