प्रगत तापमानवाढ
शेड्यूल विंडो, मल्टी-रिजन वार्मिंग, ब्राउझर/SSR रेंडरिंग आणि मोबाइल वापरकर्ता एजंट.
12 min read
सेटअपसाठी चार क्षमता ज्या साध्या तासाला HTTP क्रॉल करत नाहीत. सर्व प्लॅन-गेट केलेले आहेत — तुमच्या फॉर्ममधून एखादा गहाळ असल्यास, तो तुमच्या सबस्क्रिप्शनमध्ये समाविष्ट केलेला नाही.
उबदार शेड्यूल विंडो
डीफॉल्टनुसार सक्रिय वॉर्मर प्रत्येक स्वयं-प्रारंभ मध्यांतराने, चोवीस तास नवीन रन सुरू करतो. शेड्यूल विंडो हे तुम्ही निवडलेल्या तासांपुरते मर्यादित करा.
खिडकीच्या बाहेर, अनुसूचित स्वयं-प्रारंभ वगळले आहेत. मॅन्युअल स्टार्ट, डिप्लॉय ट्रिगर आणि CDN शुद्धीकरण-रिवार्म क्रिया अजूनही कार्य करतात — विंडो शेड्यूल नियंत्रित करते, संपूर्णपणे उबदार नाही.
तुम्हाला हे का हवे असेल
- शिखराच्या आधी उबदार. तुमच्या सर्वात व्यस्त कालावधीच्या काही तास आधी रॅम्प करा जेणेकरून जेव्हा रहदारी येते तेव्हा सर्वकाही गरम असते.
- रात्रभर परत बंद. कोणीही भेट देत नसताना विनंती बजेट आणि मूळ लोड जतन करा.
- देखभाल खिडक्या संरक्षित करा. बॅकअप, स्थलांतर किंवा बॅच जॉब दरम्यान तापमानवाढ थांबवा.
- संपादकीय लय जुळवा. सकाळच्या वाचनापूर्वी न्यूजरूम बऱ्याचदा खूप उबदार होतात.
JSON स्वरूप
उबदार शेड्यूल फील्ड टाइमझोन आणि विंडोच्या सूचीसह 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 सामान्य आहे; कमी मूल्य अधिक हळूवारपणे गरम होते. |
{
"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 सर्व्हर परत मिळवते. बऱ्याच साइट्ससाठी तेच कॅशे केले जाते आणि तेच तुम्हाला हवे आहे.
काही स्टॅक वेगळे आहेत. जर तुम्हाला महत्त्वाचा असलेला कॅशे लेयर पूर्ण रेंडरनंतरच भरला असेल — एक JavaScript-हेवी फ्रंट एंड, किंवा फ्रेमवर्क ज्याची कॅशे कच्च्या विनंतीऐवजी संपूर्ण नेव्हिगेशनवर भरते — साधे आणणे काहीही उपयुक्त नाही.
ब्राउझर / SSR वार्मिंग पृष्ठ योग्यरित्या लोड करण्यासाठी वास्तविक ब्राउझर इंजिन वापरते. ही एक बिझनेस-प्लॅन क्षमता आहे, प्रति वॉर्मर सक्षम आहे.
| साधा HTTP तापमानवाढ वापरा जेव्हा… | ब्राउझर वार्मिंग वापरा जेव्हा… |
|---|---|
| तुमचा सर्व्हर पूर्ण परतावा HTML | पृष्ठ क्लायंट-साइड एकत्र केले आहे |
| A CDN किंवा पृष्ठ कॅशे प्रतिसाद संचयित करते | पूर्ण रेंडर पास केल्यानंतरच कॅशे भरते |
| तुम्हाला जास्तीत जास्त थ्रुपुट स्वस्तात हवे आहे | व्हॉल्यूमपेक्षा अचूकता महत्त्वाची आहे |
| सर्वाधिक स्थिर आणि पारंपारिक CMS साइट | SSR/ISR ॲप-राउटर शैलीचे मार्ग जे भरत नाहीत |
ब्राउझर वार्मिंग जास्त जड आहे
ब्राउझरमध्ये पृष्ठ प्रस्तुत करण्यासाठी ते मिळवण्यापेक्षा कितीतरी जास्त वेळ आणि संसाधने खर्च होतात. ज्या मार्गांची खरोखर गरज आहे त्यांच्यासाठी निवडकपणे वापरा आणि इतर सर्व गोष्टींसाठी हलके HTTP वार्मिंग ठेवा. दर मर्यादा कमी केल्याशिवाय संपूर्ण मोठ्या वॉर्मरला ब्राउझर मोडवर स्विच करू नका.
व्यावहारिक चाचणी: प्रथम सामान्य HTTP गरम चालवा. तुमची उर्वरित साइट सुधारत असताना कॅशे हेल्थ ते मार्ग अजूनही थंड दाखवत असल्यास, ब्राउझर वार्मिंग प्रयत्न करण्यासारखे आहे.
मोबाईल वार्मिंग
तुमची CDN वापरकर्ता एजंटद्वारे त्याची कॅशे केलेली प्रत बदलत असल्यास, किंवा तुम्ही विशिष्ट मोबाइल टेम्पलेट सर्व्ह करत असल्यास, केवळ डेस्कटॉप एजंटसह वार्मिंग फोन अभ्यागतांना थंड कॅशेवर सोडते — सामान्यतः तुमची बहुतांश रहदारी.
तसेच मोबाइल वापरकर्ता एजंटसह क्रॉल करण्यासाठी उबदार मोबाइल आवृत्ती चालू करा. यास परवानगी देणाऱ्या योजनांवर तुम्ही अचूक नियंत्रणासाठी तुमचे स्वतःचे मोबाइल वापरकर्ता एजंट देखील पुरवू शकता.
- तुमच्या कॅशे कीमध्ये वापरकर्ता एजंट किंवा डिव्हाइस वर्ग समाविष्ट असल्यास आवश्यक.
- तुम्ही स्वतंत्र मोबाइल थीम किंवा
m.सबडोमेन सर्व्ह करत असल्यास आवश्यक. - तुम्ही प्रत्येक डिव्हाइसला एकसमान प्रतिसाद देणारे HTML सर्व्ह करत असल्यास अनावश्यक — एक कॅश्ड प्रत आधीपासून सर्वांना सर्व्ह करते.
Note
वॉर्मिंग डेस्कटॉप आणि मोबाइल व्हेरियंट्स विनंतीचा व्हॉल्यूम अंदाजे दुप्पट करतात, कारण प्रत्येक URL दोन्ही एजंट अंतर्गत आणले जाते. मोठ्या साइटवर सक्षम करण्यापूर्वी तुमची दर मर्यादा तपासा आणि बजेटचे नियोजन करा.
सानुकूल वापरकर्ता एजंट
वापरकर्ता एजंट फील्ड तुम्हाला नेमक्या कोणत्या एजंट स्ट्रिंगच्या विनंत्या पाठवल्या जातात हे सेट करू देते. तुम्ही कारणे करू शकता:
- तुमची CDN कॅशे विशिष्ट एजंट स्ट्रिंगवर ठेवते आणि तुम्हाला ते तंतोतंत जुळणे आवश्यक आहे.
- बॉट फिल्टर अज्ञात एजंटना ब्लॉक करतो आणि तुम्ही एखाद्या विशिष्ट एजंटला परवानगी दिली आहे.
- तुम्हाला तुमच्या सर्व्हर लॉगमध्ये ओळखण्यायोग्य उबदार विनंत्या हव्या आहेत, त्यांना वास्तविक रहदारीपासून वेगळे करण्यासाठी.
Tip
तापमानवाढीसाठी विशिष्ट, ओळखण्यायोग्य वापरकर्ता एजंट वापरणे हा चांगला सराव आहे. हे तुमच्या विश्लेषण आणि प्रवेश नोंदींमध्ये Cache Rocket रहदारी स्पष्ट करते आणि अहवालातून वगळणे सोपे करते.