सर्वर रहित सर्वर में सर्वर रेंडरिंग

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

ट्रेनिंग

माप बनाने के लिए जो परियोजना की समस्याओं को पहचानने में मदद करेगा, हम webpagetest.org का उपयोग करेंगे। इस संसाधन की मदद से, हम अनुरोधों को पूरा करेंगे और विभिन्न अभियानों के निष्पादन समय के बारे में जानकारी एकत्र करेंगे। यह हमें यह समझने में मदद करेगा कि परियोजना के साथ काम करते समय उपयोगकर्ता क्या देखते हैं और महसूस करते हैं।

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

साइट लोडिंग की सुविधाओं को दर्शाते संकेतक - समस्याओं की पहचान

निम्नलिखित चार्ट पर एक नज़र डालें।


एक वेब परियोजना के पुराने और नए संकेतकों का विश्लेषण

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


(1) जेएस बंडल डाउनलोड करें। (2) मुख्य धागे में बंडल प्रसंस्करण की प्रतीक्षा कर रहा है

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


पेज लोड हो रहा है

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


पेज लोड हो रहा है

यदि परियोजना को नियमित VPS पर होस्ट किया गया था, तो इन API अनुरोधों को पूरा करने के लिए आवश्यक समय ज्यादातर अनुमानित होगा। हालाँकि, सर्वर रहित वातावरण में चल रहे प्रोजेक्ट कुख्यात "कोल्ड स्टार्ट" समस्या से प्रभावित होते हैं। वेबिन क्लाउड प्लेटफॉर्म के मामले में स्थिति और भी खराब है। AWS लाम्बा सुविधाएँ VPC (वर्चुअल प्राइवेट क्लाउड) का हिस्सा हैं। इसका मतलब यह है कि ऐसे फ़ंक्शन के प्रत्येक नए उदाहरण के लिए, आपको ENI (इलास्टिक नेटवर्क इंटरफ़ेस, इलास्टिक नेटवर्क इंटरफ़ेस) को इनिशियलाइज़ करना होगा। यह कार्यों के ठंड शुरू होने के समय को काफी बढ़ा देता है।

यहां VWS के भीतर और VPC के बाहर AWS लैंबडा फीचर्स लोड करने के लिए कुछ समयसीमा दी गई है।


VPC के अंदर और VPC के बाहर AWS लैंबडा फंक्शन लोड विश्लेषण ( यहाँ से ली गई छवि)

इससे हम यह निष्कर्ष निकाल सकते हैं कि जब VPC के अंदर फ़ंक्शन लॉन्च किया जाता है, तो यह ठंड शुरू होने के समय में 10 गुना वृद्धि देता है।

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

अनुकूलन कार्य

उपरोक्त विश्लेषण के आधार पर, हमने कई कार्यों की रूपरेखा तैयार की जिन्हें हमें परियोजना को अनुकूलित करने के लिए हल करने की आवश्यकता थी। यहाँ वे हैं:

• एपीआई अनुरोधों को निष्पादित करने या ब्लॉक करने वाले एपीआई अनुरोधों की संख्या को कम करने की गति में सुधार।
• जेएस बंडल के आकार को कम करना या इस बंडल को उन संसाधनों में परिवर्तित करना जो पृष्ठ के आउटपुट के लिए आवश्यक नहीं हैं।
• मुख्य धागे को अनलॉक करना।

समस्या दृष्टिकोण

यहां उन समस्याओं को हल करने के लिए कुछ दृष्टिकोण दिए गए हैं जिन पर हमने विचार किया:

1. इसके निष्पादन में तेजी लाने के लिए कोड अनुकूलन। इस दृष्टिकोण को बहुत प्रयास करने की आवश्यकता है, इसकी उच्च लागत है। ऐसे अनुकूलन के परिणामस्वरूप मिलने वाले लाभ संदिग्ध हैं।
2. AWS लैम्ब्डा सुविधाओं के लिए उपलब्ध RAM की मात्रा बढ़ाएँ। ऐसा करना आसान है, इस तरह के समाधान की लागत मध्यम और उच्च के बीच कहीं है। इस समाधान के आवेदन से केवल छोटे सकारात्मक प्रभावों की उम्मीद की जा सकती है।
3. समस्या को हल करने के लिए किसी अन्य तरीके का उपयोग। सच है, उस समय हमें अभी तक नहीं पता था कि यह विधि क्या थी।

अंत में, हमने इस सूची में तीसरा आइटम चुना। हमने इस तरह तर्क दिया: “क्या होगा अगर हमें एपीआई कॉल की बिल्कुल आवश्यकता नहीं है? क्या होगा अगर हम जेएस बंडल के बिना बिल्कुल भी कर सकते हैं? यह हमें परियोजना की सभी समस्याओं को हल करने की अनुमति देगा। ”


पहला विचार जो हमें दिलचस्प लगा वह था कि प्रदान किए गए पृष्ठ का HTML स्नैपशॉट बनाना और उपयोगकर्ताओं के साथ स्नैपशॉट साझा करना।

असफल प्रयास

Webiny Cloud एक AWS लैंबडा-आधारित सर्वर रहित बुनियादी ढाँचा है जो Webiny साइटों का समर्थन करता है। हमारा सिस्टम बॉट्स का पता लगा सकता है। जब यह पता चलता है कि अनुरोध बॉट द्वारा पूरा किया गया था, तो यह अनुरोध प्यूपेटर उदाहरण के लिए पुनर्निर्देशित किया गया है, जो उपयोगकर्ता इंटरफ़ेस के बिना क्रोम का उपयोग करते हुए पृष्ठ को प्रस्तुत करता है। पृष्ठ का तैयार HTML कोड बॉट में भेजा जाता है। यह मुख्य रूप से एसईओ कारणों से किया गया था, इस तथ्य के कारण कि कई बॉट्स जावास्क्रिप्ट को निष्पादित करने का तरीका नहीं जानते हैं। हमने सामान्य उपयोगकर्ताओं के लिए इच्छित पृष्ठों को तैयार करने के लिए उसी दृष्टिकोण का उपयोग करने का निर्णय लिया।


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

पेश है SSR

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

SSR का उपयोग करने का एक अतिरिक्त लाभ यह है कि हम क्लाइंट को पेज का ऐसा HTML संस्करण देते हैं, जिसके साथ काम करते समय, JS फ़ाइलों को लोड करने के बाद, प्रतिक्रिया घटकों को बढ़ते हुए समस्या नहीं होती है।

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

सामान्य तौर पर, हम कह सकते हैं कि सर्वर रेंडरिंग, ऐसा लगता है, हमारी अधिकांश समस्याओं को हल करना चाहिए था।

सर्वर-साइड रेंडरिंग को लागू करने के बाद साइट विश्लेषण कैसा दिखता है।


सर्वर रेंडरिंग लागू करने के बाद साइट मेट्रिक्स

अब एपीआई अनुरोधों को निष्पादित नहीं किया जाता है, और बड़े जेएस बंडल लोड से पहले पृष्ठ को देखा जा सकता है। लेकिन अगर आप पहले अनुरोध को करीब से देखते हैं, तो आप देख सकते हैं कि सर्वर से दस्तावेज़ प्राप्त करने में लगभग 2 सेकंड लगते हैं। चलिए इसके बारे में बात करते हैं।

TTFB के साथ समस्या

यहां हम TTFB मीट्रिक (टाइम टू फर्स्ट बाइट, टाइम टू फर्स्ट बाइट) पर चर्चा करते हैं। यहां पहले अनुरोध का विवरण दिया गया है।


पहला अनुरोध विवरण

इस पहले अनुरोध को संसाधित करने के लिए, हमें निम्नलिखित करने की आवश्यकता है: Node.js सर्वर लॉन्च करना, सर्वर रेंडरिंग करना, एपीआई अनुरोध करना और जेएस कोड निष्पादित करना और फिर अंतिम परिणाम ग्राहक को वापस करना। यहां समस्या यह है कि यह सब, औसतन, 1-2 सेकंड लेता है।

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

यहाँ आप शब्द "सर्वर" के बारे में एक प्रश्न हो सकता है। हम इस समय सर्वर रहित प्रणाली के बारे में बात कर रहे हैं। यह "सर्वर" कहां से आया? हम, निश्चित रूप से, AWS लैम्ब्डा फ़ंक्शन में सर्वर रेंडरिंग को रेंडर करने की कोशिश की। लेकिन यह पता चला कि यह एक बहुत ही संसाधन-खपत प्रक्रिया है (विशेष रूप से, अधिक प्रोसेसर संसाधन प्राप्त करने के लिए मेमोरी की मात्रा को बहुत अधिक बढ़ाना आवश्यक था)। इसके अलावा, "कोल्ड स्टार्ट" समस्या, जिसे हमने पहले ही उल्लेख किया है, को भी यहाँ जोड़ा गया है। परिणामस्वरूप, तब आदर्श समाधान एक Node.js सर्वर का उपयोग करना था जो साइट सामग्री को लोड करेगा और सर्वर-साइड रेंडरिंग में संलग्न करेगा।

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


सर्वर-साइड रेंडरिंग का उपयोग करते समय पृष्ठ लोड हो रहा है

उपयोगकर्ता को 2.5 सेकंड के लिए एक रिक्त पृष्ठ देखने के लिए मजबूर किया जाता है। यह दुखद है।

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

एकमात्र समस्या यह थी कि इस HTML स्नैपशॉट को बनाने में बहुत अधिक समय लगा। इस बिंदु पर, हम सर्वर रेंडर को अनुकूलित करने में अधिक समय लगा सकते हैं, या बस इसके परिणामों को कैश कर सकते हैं और ग्राहकों को पेज के स्नैपशॉट जैसे कि रेडिस कैश से कुछ दे सकते हैं। हमने बस यही किया।

कैशिंग सर्वर रेंडरिंग परिणाम

एक उपयोगकर्ता Webiny वेबसाइट पर जाने के बाद, हम सबसे पहले यह देखने के लिए केंद्रीकृत Redis कैश की जांच करते हैं कि क्या पेज का HTML स्नैपशॉट है या नहीं। यदि हां, तो हम उपयोगकर्ता को कैश से एक पेज देते हैं। औसतन, इसने TTFB को 200-400 एमएस तक घटा दिया। यह कैश की शुरूआत के बाद था कि हमने परियोजना के प्रदर्शन में महत्वपूर्ण सुधारों को नोटिस करना शुरू किया।


सर्वर-साइड रेंडरिंग और कैश का उपयोग करते समय पृष्ठ लोड हो रहा है

यहां तक ​​कि जो उपयोगकर्ता पहली बार साइट पर जाता है, वह पृष्ठ की सामग्री को एक सेकंड से भी कम समय में देखता है।

आइए देखें कि झरना आरेख अब कैसा दिखता है।


सर्वर-साइड रेंडरिंग और कैशिंग लागू करने के बाद साइट मेट्रिक्स

लाल रेखा 800 एमएस के समय टिकट को इंगित करती है। यह वह जगह है जहाँ पृष्ठ की सामग्री पूरी तरह से भरी हुई है। इसके अलावा, यहां आप देख सकते हैं कि JS बंडल लगभग 1.3 s पर लोड किया गया है। लेकिन यह उस समय को प्रभावित नहीं करता है जो उपयोगकर्ता को पृष्ठ देखने की आवश्यकता होती है। उसी समय, आपको पृष्ठ प्रदर्शित करने के लिए एपीआई कॉल करने और मुख्य धागे को लोड करने की आवश्यकता नहीं है।

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

मान लीजिए कि एक पृष्ठ "गतिशील" है। उदाहरण के लिए, यह उस घटना में उपयोगकर्ता खाते तक पहुंचने के लिए हैडर में एक लिंक प्रदर्शित करता है जो उपयोगकर्ता जो पृष्ठ देख रहा है वह लॉग इन है। सर्वर-साइड रेंडरिंग के बाद, सामान्य-प्रयोजन पृष्ठ ब्राउज़र को भेजा जाएगा। वह है - एक ऐसा उपयोगकर्ता जो लॉग इन नहीं है। इस पृष्ठ का शीर्षक बदल जाएगा, इस तथ्य को दर्शाती है कि उपयोगकर्ता ने जेएस बंडल लोड होने और एपीआई कॉल किए जाने के बाद ही लॉग इन किया है। यहां हम TTI इंडिकेटर (टाइम टू इंटरएक्टिव, टाइम टू फर्स्ट इंटरेक्टिविटी) के साथ काम कर रहे हैं।

कुछ हफ़्ते बाद, हमने पाया कि हमारा प्रॉक्सी सर्वर उस क्लाइंट के साथ कनेक्शन बंद नहीं करता है जहाँ इसकी ज़रूरत होती है, अगर बैकग्राउंड प्रोसेस के रूप में सर्वर रेंडरिंग लॉन्च किया गया था। कोड की शाब्दिक रूप से एक पंक्ति के सुधार ने इस तथ्य को जन्म दिया कि TTFB संकेतक 50-90 एमएस के स्तर तक कम हो गया था। नतीजतन, साइट अब लगभग 600 एमएस के बाद ब्राउज़र में प्रदर्शित होने लगी।

हालाँकि, हमने एक और समस्या का सामना किया ...

कैश अमान्यकरण समस्या

"कंप्यूटर विज्ञान में, केवल दो जटिल चीजें हैं: कैश अमान्यकरण और इकाई का नामकरण।"
फिल कार्लटन

कैश अमान्यकरण, वास्तव में, एक बहुत ही मुश्किल काम है। इसे कैसे हल करें? सबसे पहले, आप अक्सर कैश्ड ऑब्जेक्ट (TTL, Time To Live, जीवनकाल) के लिए बहुत कम स्टोरेज टाइम सेट करके कैश को अपडेट कर सकते हैं। यह कभी-कभी पृष्ठों को सामान्य से अधिक धीरे-धीरे लोड करने का कारण होगा। दूसरे, आप कुछ घटनाओं के आधार पर कैश अमान्य तंत्र बना सकते हैं।

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

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

नतीजतन, हम हमेशा कैश से क्लाइंट्स के लिए पेज लौटाते हैं, और जब कैश डेटा की उम्र 30 सेकंड तक पहुंच जाती है, तो कैश की सामग्री अपडेट हो जाती है।

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

उदाहरण के लिए, मान लीजिए कि एक संसाधन का मुखपृष्ठ तीन सबसे हालिया ब्लॉग पोस्ट प्रदर्शित करता है। यदि नया पृष्ठ प्रकाशित होने पर कैश अपडेट किया जाता है, तो तकनीकी दृष्टिकोण से, इस नए पृष्ठ के लिए केवल कैश प्रकाशन के बाद उत्पन्न होगा। मुख पृष्ठ के लिए कैश पुराना हो जाएगा।

हम अभी भी अपने प्रोजेक्ट के कैशिंग सिस्टम को बेहतर बनाने के तरीकों की तलाश कर रहे हैं। लेकिन अब तक, मौजूदा प्रदर्शन मुद्दों को सुलझाने पर ध्यान केंद्रित किया गया है। हम मानते हैं कि हमने इन समस्याओं को हल करने के मामले में काफी अच्छा काम किया है।

परिणाम

सबसे पहले, हमने क्लाइंट-साइड रेंडरिंग का उपयोग किया। फिर, औसतन, उपयोगकर्ता 3.3 सेकंड में पृष्ठ देख सकता था। अब, यह आंकड़ा लगभग 600 एमएस तक गिर गया है। यह भी महत्वपूर्ण है कि अब हम डाउनलोड इंडिकेटर के साथ डिस्पेंस करें।

इस परिणाम को प्राप्त करने के लिए, हमें अनुमति दी गई, मुख्य रूप से, सर्वर रेंडरिंग का उपयोग। , . , , , , .

, . , . . . , , , , .

, — . , , . , . . . — , , . , .

! ?