- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
यह AI द्वारा अनुवादित पोस्ट है।
durumis AI द्वारा सारांशित पोस्ट
- वेबपेज ट्रांसफर स्पीड में सुधार और क्लाउड रन-आधारित रीडायरेक्ट सेवा को लागू करके Google सर्च क्रॉलिंग बजट को कुशलतापूर्वक इस्तेमाल करने के लिए हमने कदम उठाए हैं।
- robots.txt, favicon.ico जैसी स्थिर फ़ाइलों और रीडायरेक्शन लॉजिक को क्लाउड रन में स्थानांतरित करके, हमने मौजूदा GKE ऑटोपायलट की तुलना में प्रतिक्रिया समय को 200ms से घटाकर 20ms कर दिया है।
- दुनिया भर के विभिन्न क्षेत्रों में क्लाउड रन को तैनात करके, हम उपयोगकर्ता के स्थान के करीब सर्वर से सेवा प्रदान करते हैं, जिससे गति में सुधार और लागत में कमी का लाभ मिलता है।
सभी सामग्री पर आधारित सेवाएँ Google खोज में अधिक दिखाई देना चाहती हैं।
लेकिन, Google खोज में दिखाई देने के लिए, क्रॉलर को अक्सर नवीनतम डेटा क्रॉल करने के लिए आना चाहिए, और उसे अच्छी तरह से प्रतिबिंबित करना चाहिए।
इस समय, क्रॉलर को वेबसाइट पर अधिक बार आने के लिए, "क्रॉलिंग बजट (Crawling Budget)" का उपयोग करके, यदि बजट अधिक है तो यह अधिक बार आ सकता है, और इसके लिए साइट को कुछ ट्रैफ़िक प्राप्त करना होगा।
तो इस सीमित "क्रॉलिंग बजट" का प्रभावी ढंग से उपयोग कैसे किया जाए ताकि समान बजट में यह अधिक बार आ सके?
इसके लिए साइट का वेबपेज ट्रांसमिशन स्पीड तेज होना चाहिए। उदाहरण के लिए, 200ms में पेज डाउनलोड करने वाली साइट की तुलना में 20ms में पेज डाउनलोड करने वाली साइट अधिक बार पेज क्रॉल करती है।
हमारी दुर्मीस मूल रूप से "ग्लोबल सर्विस" का लक्ष्य रखती है, इसलिए हम दुनिया भर के 8 क्षेत्रों में बुनियादी ट्रैफ़िक सेवा प्रदान कर रहे हैं।
GCP सर्वर क्षेत्र
वर्तमान में, हमारी सेवा मूल रूप से Google के 40 क्षेत्रों (Google's 40 regions)में से एशिया के सियोल, सिंगापुर, मुंबई, यूरोप के बेल्जियम, अमेरिका के लॉस एंजिल्स, साउथ कैरोलिना में स्थित क्षेत्रों का उपयोग कर रही है। दुनिया में कहीं से भी कनेक्ट होने पर, यह आम तौर पर धीमा नहीं होता है।
लेकिन, ऊपर बताए गए कारणों से, हम थोड़ा और ट्यूनिंग करने का फैसला किया है ताकि और अधिक गति प्राप्त हो सके।
वर्तमान में हमारी सेवा शुरुआती लॉन्च के समय से URL तरीके से एक नए सबडोमेन तरीके में बदल रही है, इसलिए कुछ रीडायरेक्ट हैं, और इस हिस्से में Google के क्रॉलर का बहुत अधिक दौरा होता है। Google को पुराने URL को नए URL से जल्दी से पहचानने की आवश्यकता है।
इसलिए, दिए गए क्रॉलर बजट का अधिकतम उपयोग करने के लिए, रीडायरेक्ट ट्रैफ़िक को अधिकतम गति बनाए रखने की आवश्यकता है।
पहले, ऊपर बताए गए 8 क्षेत्रों में GKE तैनात किया गया था, और प्रत्येक GKE Google के GKE ऑटोपायलट (GKE Autopilot)का उपयोग करके DB से न जुड़े डेटा का उपयोग करके रीडायरेक्ट कर रहा था।
इसलिए, इस बार हम GKE में मौजूद और पहले Cloud Run में मौजूद कुछ लॉजिक को नए Cloud Run में स्थानांतरित करने जा रहे हैं। स्थानांतरित करने की सूची इस प्रकार है:
- robots.txt: यह एक स्थिर फ़ाइल है, लेकिन कई सबडोमेन में कुछ लॉजिक के साथ सामग्री प्रदान की जा रही है।
- favicon.ico: शुद्ध स्थिर फ़ाइल
- durumis.com/[lang]/@userId/postID: नया URL पर रीडायरेक्ट करें -> userId.durumis.com/[lang]/postID
पहले, जब GKE ऑटोपायलट में थोड़ा भारी फ्रेमवर्क का उपयोग करके इसे परोसा गया था, तो यह लगभग 200ms का प्रतिक्रिया समय दिखाता था।
नया तरीका Cloud Run का उपयोग करके इसे चलाना है, और चूँकि लॉजिक बहुत सरल है, इसलिए हम फ्रेमवर्क का उपयोग नहीं कर रहे हैं, और node:http का उपयोग करके लाइब्रेरी के बिना मूल कोड का उपयोग कर रहे हैं।
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
(यदि आप ऊपर दिए गए कोड को सीधे डालते हैं, तो यह काम नहीं करेगा। आपको बस अवधारणा को समझना होगा।)
favicon.ico के मामले में, चूँकि यह एक छवि फ़ाइल है, इसलिए हम इसे फ़ाइल से लोड करते हैं, इसे मेमोरी में रखते हैं, और इसे भेजने के लिए उपयोग करते हैं।
हम कई क्षेत्रों में एक साथ परिनियोजन करने के लिए gcloud का उपयोग करके शेल स्क्रिप्ट का उपयोग करते हैं।
वोइला..
इस तरह से परिनियोजन के परिणाम इस प्रकार हैं:
क्लाउड रन स्क्रीन
हमने अमेरिका के "सभी क्षेत्रों" में परिनियोजन किया है, और प्रत्येक महाद्वीप के लिए यूरोप में 2, एशिया में 2, अफ्रीका में 1 और दक्षिण अमेरिका में 2 क्षेत्रों में परिनियोजन किया है। वास्तव में, यह सर्वरलेस का लाभ है, और भले ही हम ऐसा करें, लागत में कोई वृद्धि नहीं होती है। (वास्तव में, यदि हम निकटतम क्षेत्र से ट्रैफ़िक की सेवा करते हैं, तो लागत कम हो सकती है।)
तो, इस तरह से गति कितनी तेज हो गई है?
सर्वर-साइड प्रतिक्रिया समय पहले इस प्रकार था:
GKE ऑटोपायलट
सुधारित गति इस प्रकार है:
क्लाउड रन का उपयोग करके स्टेटिक फ़ाइल
निश्चित रूप से, क्योंकि Cloud Run सर्वरलेस है, इसलिए कोल्ड स्टार्ट समय होगा, लेकिन जब क्रॉलर नियमित रूप से क्रॉल करता है, तो यह वास्तव में कोई समस्या नहीं है। GCP के सर्वरलेस की विशेषताओं में से एक यह है कि यह स्टैंडबाय और आइडल के बीच स्विच करता रहता है। (और यह लागत में वृद्धि नहीं करता है।)
अगले पोस्ट में, हम ऊपर बताई गई छोटी स्थिर फ़ाइलों या 301 रीडायरेक्ट के अलावा, छवि फ़ाइलों और अन्य फ़ाइलों के बारे में बताएंगे।