उन्नत वार्मिंग

विंडोज़, मल्टी-रीजन वार्मिंग, ब्राउज़र/SSR रेंडरिंग और मोबाइल उपयोगकर्ता एजेंटों को शेड्यूल करें।

12 मिनट पढ़ें

सेटअप के लिए चार क्षमताएं जिन्हें एक सामान्य प्रति घंटा HTTP क्रॉल कवर नहीं करता है। सभी योजनाबद्ध हैं - यदि आपके फॉर्म से कोई गायब है, तो यह आपकी सदस्यता में शामिल नहीं है।

वार्म शेड्यूल विंडो

डिफ़ॉल्ट रूप से एक सक्रिय वार्मर चौबीसों घंटे हर ऑटो-स्टार्ट अंतराल पर एक नया रन शुरू करता है। शेड्यूल विंडो उसे आपके द्वारा चुने गए घंटों तक सीमित रखती है।

एक विंडो के बाहर, निर्धारित ऑटो-स्टार्ट को छोड़ दिया जाता है। मैन्युअल प्रारंभ, ट्रिगर तैनात करना, और CDN पर्ज-रिवार्म क्रियाएं अभी भी काम करती हैं - विंडो शेड्यूल को नियंत्रित करती है, न कि समग्र रूप से वार्मर को।

आप ऐसा क्यों चाहेंगे

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

JSON प्रारूप

वार्म शेड्यूल फ़ील्ड एक समयक्षेत्र और विंडोज़ की सूची के साथ एक JSON ऑब्जेक्ट लेता है:

कार्यदिवस, 08:00–20:00, एम्स्टर्डम समय

json

{
  "timezone": "Europe/Amsterdam",
  "windows": [
    { "days": [1, 2, 3, 4, 5], "startHour": 8, "endHour": 20, "intensity": 1 }
  ]
}

मैदान	अर्थ
WordPress	एक IANA समयक्षेत्र नाम जैसे `Europe/Amsterdam`, `America/New_York`, या `UTC`। इस क्षेत्र में विंडोज़ का मूल्यांकन किया जाता है, इसलिए आपके लिए डेलाइट सेविंग का प्रबंधन किया जाता है।
WordPress	समय विंडो की एक सूची. उनमें से किसी के अंदर दौड़ने की अनुमति है।
WordPress	यह विंडो सप्ताह के उन दिनों पर लागू होती है, जहां `1` सोमवार है और `7` रविवार है।
WordPress	खिड़की खुलने का समय, `0`–`23`।
WordPress	जैसे ही खिड़की बंद होती है, `0`–`23`।
WordPress	खिड़की के दौरान सापेक्ष वार्मिंग प्रयास। `1` सामान्य है; कम मूल्य अधिक धीरे से गर्म होता है।

दो खिड़कियाँ - चरम से पहले कठोर, रात भर कोमल

json

{
  "timezone": "Europe/Amsterdam",
  "windows": [
    { "days": [1, 2, 3, 4, 5], "startHour": 6, "endHour": 10, "intensity": 1 },
    { "days": [1, 2, 3, 4, 5, 6, 7], "startHour": 0, "endHour": 5, "intensity": 0.3 }
  ]
}

जाँच करें कि खिड़की समाप्त करने के लिए पर्याप्त चौड़ी है

यदि एक पूर्ण पास में तीन घंटे लगते हैं और आपकी विंडो दो घंटे की है, तो रन कम कर दिए जाएंगे और बाद में URLs कभी गर्म नहीं होगा। या तो खिड़की चौड़ी करें, दर सीमा बढ़ाएँ, या वार्मर का दायरा कम करें।

Tip

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

बहु-क्षेत्रीय तापन

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

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

जब तुम्हें इसकी जरूरत हो

आपके पास एक से अधिक महाद्वीपों पर सार्थक ट्रैफ़िक है।
आपका CDN वैश्विक स्तर के बजाय प्रति POP या प्रति क्षेत्र कैश करता है।
आप क्षेत्र-विशिष्ट मूल से स्थानीयकृत सामग्री परोसते हैं।
आप एक मल्टी-CDN सेटअप चलाते हैं जहां व्यवहार भूगोल के अनुसार भिन्न होता है।

यदि आपके लगभग सभी आगंतुक एक ही देश में हैं, तो एक ही क्षेत्र ठीक है और बहु-क्षेत्र लाभ के बिना लागत जोड़ता है।

अधिक क्षेत्रों से वार्मिंग अनुरोधों को कई गुना बढ़ा देती है

प्रत्येक क्षेत्र अपने स्वयं के अनुरोध जारी करता है, इसलिए तीन क्षेत्रों को कवर करने से अनुरोध की मात्रा लगभग तीन गुना हो जाती है - आपके मूल और आपकी योजना के URL बजट दोनों के मुकाबले। अपनी दर सीमा को तदनुसार आकार दें।

अपने वास्तविक विश्लेषण से क्षेत्र चुनें, आकांक्षा से नहीं। आपके ट्रैफ़िक का दो प्रतिशत उत्पन्न करने वाले क्षेत्र को गर्म करना शायद ही अनुरोध बजट को तिगुना करने के लायक है।

ब्राउज़र / SSR वार्मिंग

एक सादा HTTP फ़ेच एक सर्वर द्वारा लौटाए गए HTML को पुनः प्राप्त करता है। अधिकांश साइटों के लिए यह वही है जो कैश किया जाता है, और यह वह सब है जिसकी आपको आवश्यकता है।

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

ब्राउज़र / SSR वार्मिंग पेज को ठीक से लोड करने के लिए एक वास्तविक ब्राउज़र इंजन का उपयोग करता है। यह एक व्यवसाय-योजना क्षमता है, जो प्रति वार्मर सक्षम है।

सादे HTTP वार्मिंग का उपयोग करें जब…	ब्राउज़र वार्मिंग का उपयोग तब करें जब…
आपका सर्वर पूर्ण HTML लौटाता है	पेज क्लाइंट-साइड असेंबल किया गया है
एक CDN या पेज कैश प्रतिक्रिया संग्रहीत करता है	पूर्ण रेंडर पास के बाद ही कैश भरता है
आप सस्ते में अधिकतम थ्रूपुट चाहते हैं	मात्रा से अधिक शुद्धता मायने रखती है
अधिकांश स्थिर और पारंपरिक CMS साइटें	SSR/ISR ऐप-राउटर स्टाइल रूट जो भर नहीं रहे हैं

ब्राउज़र वार्मिंग बहुत अधिक है

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

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

मोबाइल वार्मिंग

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

मोबाइल उपयोगकर्ता एजेंटों के साथ भी क्रॉल करने के लिए वार्म मोबाइल संस्करण चालू करें। इसकी अनुमति देने वाली योजनाओं पर आप सटीक नियंत्रण के लिए अपने स्वयं के मोबाइल उपयोगकर्ता एजेंट भी प्रदान कर सकते हैं।

यदि आपकी कैश कुंजी में उपयोगकर्ता एजेंट या डिवाइस वर्ग शामिल है तो यह आवश्यक है।
यदि आप एक अलग मोबाइल थीम या m. उपडोमेन परोसते हैं तो यह आवश्यक है।
यदि आप प्रत्येक डिवाइस पर समान प्रतिक्रियाशील HTML परोसते हैं तो यह अनावश्यक है - एक कैश्ड कॉपी पहले से ही सभी को सेवा प्रदान करती है।

Note

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

कस्टम उपयोगकर्ता एजेंट

उपयोगकर्ता एजेंट फ़ील्ड आपको सटीक रूप से सेट करने देता है कि कौन से एजेंट स्ट्रिंग अनुरोध भेजे गए हैं। आपके कारण ये हो सकते हैं:

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

Tip

वार्मिंग के लिए एक विशिष्ट, पहचान योग्य उपयोगकर्ता एजेंट का उपयोग करना अच्छा अभ्यास है। यह आपके एनालिटिक्स और एक्सेस लॉग में Cache Rocket ट्रैफ़िक को स्पष्ट बनाता है, और रिपोर्टिंग से बाहर करना आसान बनाता है।

वार्म शेड्यूल विंडो#