API के माध्यम से पेज के बैकलिंक्स की जाँच करें और इसे ईमानदारी से कैश करें
हमारा इंडेक्स महीने में एक बार अपडेट होता है, इसलिए अधिकांश लुकअप मेमोरी से सेवा किए जा सकते हैं। कैश की एक रेसिपी जो क्रेडिट बचाती है और उपयोगकर्ताओं को पुरानी गलत जानकारी नहीं दिखाती।
AlfaLinks editorial team ·
नियम
अगले इंडेक्स रिफ्रेश तक कैश करें, निश्चित घंटे के लिए नहीं
चूंकि डेटा लगभग मासिक रूप से बदलता है, एक घंटे की TTL केवल लागत खरीदती है। महीने-स्कोप्ड कुंजी पूरे महीने के लिए समान उत्तर देती है और एक ही कदम से अमान्य हो जाती है।
कुंजी: क्रिया + डोमेन + पैरामीटर + इंडेक्स माह
TTL: महीने के अंत तक, प्लस एक दिन की छूट
कभी भी त्रुटि प्रतिक्रिया को कैश न करें
क्यों एक छोटी TTL आपके क्रेडिट बैलेंस के लिए बस एक दान है
लिंक डेटा से नई टीमें रैंक ट्रैकरों से आदतें कॉपी करती हैं। आदत नंबर एक: एक घंटे का कैश, क्योंकि स्थानियां बदलती हैं। लिंक ग्राफ़ लगभग नहीं बदलते।
एक 2-क्रेडिट backlinks कॉल की लागत $0.0002 है। यह कुछ भी नहीं लगता जब तक कि एक लिस्ट व्यू पेज लोड के दौरान 50 कॉल न चलाए, 400 सक्रिय वर्कस्पेस के लिए, हर घंटे समान उत्तरों के लिए।
नीचे दिए गए गणना उदाहरण हैं, किसी के ट्रैफ़िक का माप नहीं। 400 वर्कस्पेस, प्रति दिन 20 डोमेन व्यू, प्रति व्यू 2 क्रेडिट और एक 1-घंटे के कैश की कल्पना करें जो शायद केवल एक पंचम बार हिट करता है। अधिकांश व्यू अभी भी API को हिट करते हैं। एक माह कुंजी के तहत, उसी ट्रैफ़िक को केवल एक बार प्रति डोमेन और महीने में API तक पहुंचना होगा, इसलिए अंतर ही रेसिपी का मुख्य बिंदु है।
कीवर्ड रिसर्च टूल्स को ताज़ा डेटा की आवश्यकता होती है, और उन बड़े सूट अभी भी बेहतर विकल्प हैं। लिंक संदर्भ के लिए, मासिक ही उत्पाद है।
क्रिया के अनुसार TTL
सुझाया गया, अनिवार्य नहीं। सभी क्रियाएं एक ही मासिक इंडेक्स पढ़ती हैं।
क्रिया
क्रेडिट
सुझाया गया TTL
क्यों
ओवरव्यू, सांख्यिकी
0
महीने के अंत तक
मुफ्त, लेकिन आपका सर्वर अभी भी लेटेंसी बचाता है
bulk_dr
1
महीने के अंत तक
एक कॉल में पूला ग्राहक टेबल
refdomains, backlinks
2
महीने के अंत तक, पेज पैरामीटर के अनुसार
पेज, पेर, सॉर्ट को कुंजी में शामिल करें
anchors, toppages
2
महीने के अंत तक
रिफ्रेश के बीच स्थिर
search, keyword
3
7 दिन
दुर्लभ रूप से दोहराया जाता है, कैशिंग छोड़ना सस्ता है
अनुरोध उदाहरण: एक ग्राहक टेबल के लिए कैश गर्म करें
प्रति ग्राहक bulk_dr को एक बार कॉल करें, प्रति पंक्ति नहीं। एक POST बॉडी में 2,000 डोमेन तक फिट हो सकते हैं और एक क्रेडिट की लागत आती है।
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
कैश पांच चरणों में बनाएं
प्रत्येक चरण का एक काम है। एक छोड़ दें और विफलता बाद में दिखाई देती है, आमतौर पर एक बिल के रूप में।
01
कुंजी चुनें
क्रिया, डोमेन, पेजिंग और सॉर्टिंग पैरामीटर, और इंडेक्स माह का उपयोग करें। कुछ भी बाहर न छोड़ें जिसे उपयोगकर्ता बदल सकता है बिना उत्तर बदले, जैसे कि एक प्रदर्शन रंग या एक टैब का नाम।
02
पार्स्ड प्रतिक्रिया स्टोर करें
अनकॉडेड JSON को उसकी ok फ्लैग और डेटा के साथ रखें, न कि कच्चे बाइट्स को। एक बाद का व्यू तब मेमोरी से पूरा टेबल फिर से बना सकता है बिना एक दूसरी कॉल के।
03
महीने के अंत में समाप्त करें
समाप्ति को इंडेक्स माह के अंत तक सेट करें, ऊपर दिए गए नियम से छूट के दिन के साथ। हर क्रिया के लिए समान नियम का उपयोग करें, ताकि लॉजिक एक फ़ंक्शन में रहे और पांच जगहों में नहीं।
04
हर कॉल पर बैलेंस लॉग करें
प्रत्येक प्रमाणीकृत प्रतिक्रिया पर _credits ऑब्जेक्ट पढ़ें और शेष बैलेंस को अपने लॉग में लिखें। उस लाइन में एक धीमी गिरावट अक्सर पहला संकेत होती है कि एक कैश कुंजी गलत है।
05
हिट दर पर नज़र रखें
ट्रैक करें कि एक व्यू कितनी बार कैश से सेवा प्राप्त करता है। एक कम दर का मतलब है कि कुंजी बहुत विशिष्ट है, या कि उपयोगकर्ता हर विजिट पर एक नया डोमेन खोलते हैं। बजट की योजना बनाते समय दोनों खोज उपयोगी हैं।
क्या पुराना डेटा एक उत्पाद विकल्प है या एक बग?
एक लिंक आंकड़ा एक महीना पुराना हो सकता है और फिर भी उस इंडेक्स के लिए सही हो सकता है जिससे वह आया है। क्या आपकी स्क्रीन यह बताती है, यह असली सवाल है। पुराने नंबरों के बारे में अधिकांश सपोर्ट टिकट लेबलिंग समस्याएं हैं। लेबल आमतौर पर उन्हें ठीक कर देते हैं।
प्रत्येक आंकड़े को उसका इंडेक्स माह दें। इसे उपयोगकर्ताओं को दिखाएं। एक बार जब वे तारीख देख सकते हैं, तो नंबर टूटे हुए फ़ीड की तरह दिखना बंद कर देता है, और वह छोटी सी लाइन एक छोटी TTL से कहीं अधिक कर सकती है।
लिंक आंकड़े के लिए कितना पुराना बहुत पुराना है?
हमारा इंडेक्स रिफ्रेश लगभग महीने में एक बार होता है, इसलिए एक आंकड़ा जो पहले दिन कैश किया गया है उसी इंडेक्स का वर्णन करता है जो आखिरी दिन कैश किया गया था। महीने के भीतर उत्तर में कुछ भी नहीं बदलता। तब समस्या शुरू होती है जब एक उपयोगकर्ता कल के लिंक की उम्मीद करता है, और फिर समाधान एक स्पष्ट लेबल है, जैसा कि स्कोर लेबल्स में कवर किया गया है।
क्या मुफ्त ओवरव्यू कॉल्स को कैश की आवश्यकता है?
ओवरव्यू क्रिया में कोई क्रेडिट लागत नहीं है, इसलिए यहाँ कैश बैलेंस की रक्षा के बजाय गति की रक्षा करता है। आपका सर्वर हर राउंड ट्रिप के लिए भुगतान करता है, और एक पेज जो प्रति मिनट पचास बार खुलता है उसे महसूस होगा। मुफ्त उत्तरों को भी कैश करें, उसी माह कुंजी के साथ, और पेज तेज़ रहता है जबकि आपका प्रॉक्सी शांत रहता है। पब्लिक लुकअप नोट्स आगंतुकों के लिए उसी विचार को समझाते हैं।
क्या एक ताज़ा लिंक कभी कैश को छोड़कर आना चाहिए?
आमतौर पर नहीं। एक बायपास क्रेडिट की लागत करता है एक ऐसे उत्तर के लिए जो शायद कैश वाले से समान है। यदि एक ग्राहक जिद करता है, तो इंडेक्स माह समझाएं और प्रति वर्कस्पेस प्रति माह एक मैनुअल रिफ्रेश की पेशकश करें, न कि एक ओपन बटन जो कोई भी लूप में दबा सकता है।
स्टैम्पडी सुरक्षा और अन्य छोटी बातें
सिंगल-फ्लाइट: यदि दस उपयोगकर्ता एक ही डोमेन खोलते हैं, तो एक अपस्ट्रीम कॉल करें और वादे को साझा करें।
महीने के पहले एक बैकग्राउंड जॉब के साथ गर्म करें, 9 बजे जब उपयोगकर्ता आते हैं नहीं।
प्रतिक्रिया _credits.remaining को स्टोर करें और एक थ्रेशोल्ड से नीचे अलर्ट करें जिसे आप चुनते हैं।
नकारात्मक परिणाम 'डोमेन नहीं मिला' को एक महीने के बजाय एक दिन के लिए कैश करें।
UI में कैश उम्र एक्सपोज़ करें ताकि सपोर्ट 'इसे कब फेच किया गया?' का जवाब दे सके।
क्यों एक कैश लिंक चेक के लिए स्क्रैपिंग से बेहतर है
टीमें जिन्हें स्केल पर पेज के बैकलिंक्स की जाँच करने की आवश्यकता होती है अक्सर ऐसे स्क्रिप्ट्स से शुरू करती हैं जो सीधे सर्च इंजनों को क्वेरी करते हैं। वे स्क्रिप्ट्स अटक जाती हैं। वे पहले दिन सस्ती दिखती हैं, इसलिए टीमें उन्हें उतने समय तक रखती हैं जितना चाहिए। एक स्थिर API के सामने एक कैश आमतौर पर सस्ता डिज़ाइन होता है, जिसमें कम चलने वाले पार्ट्स होते हैं जिन्हें संभालना पड़ता है।
अंतर पहली चिट्ठी की तुलना में इंजीनियरिंग घंटों में दिखाई देता है। कैश को बोरिंग रखें, और उन घंटों में से अधिकांश कभी नहीं होते।
घर पर बने लिंक चेकर अटक क्यों रहते हैं?
सर्च इंजन ऑटोमेटेड क्वेरी को थ्रॉटल करते हैं, इसलिए एक स्क्रिप्ट जो पचास URL के लिए साफ चलती है, पचास हज़ार पर अटक सकती है। रीट्राइज़, प्रॉक्सी पूल और यादृच्छिक विलंबता सभी लागत जोड़ती हैं जो क्रेडिट लाइन पर कभी नहीं दिखती, और वे बिना चेतावनी के टूट जाते हैं जब लक्ष्य अपनी प्रतिक्रियाएं बदल देता है।
आप एक लंबी सूची जॉब को फिर से शुरू करने योग्य कैसे रखते हैं?
हर समाप्त डोमेन को कैश में लिखें जैसे-जैसे आगे बढ़ें। यदि जॉब बीच में रुक जाती है, तो एक रिसार्ट हर डोमेन को छोड़ देता है जिसके पास पहले से एक स्टोर्ड उत्तर है और जहां छोड़ा गया था वहां से शुरू करता है। उसी महीने के लिए कुछ भी दो बार चार्ज नहीं होता, क्योंकि कुंजी पहले से उत्तर रखती है।
जॉब को एक स्थिर गति से चलाएं, एक ही बर्स्ट में नहीं। कॉल को अलग रखने से लॉग पठनीय रहते हैं और क्रेडिट उपयोग में किसी भी बदलाव को समझाना आसान होता है।
कैश के साथ 22,000-URL सूची की लागत क्या है?
मान लीजिए कि आपको एक क्लाइंट के लिए 22,000 लिंकिंग URL की जाँच करनी है। उनमें से कई एक डोमेन साझा करते हैं, इसलिए पहले डोमेन में डुप्लिकेट हटाएं। वे 22,000 लिंक कुछ हज़ार अनूठे डोमेन में कम हो सकते हैं, और एक bulk_dr कॉल एक बार में 2,000 को ले जाती है एकल क्रेडिट के लिए। प्रत्येक परिणाम को डोमेन और महीने के अनुसार स्टोर करें, और सूची एक प्रति-URL जॉब बंद कर देती है। जॉब के बगल में एक छोटी नोट में अंकगणित रखें, ताकि अगला व्यक्ति अलग सूची आकार के साथ इसे फिर से चला सके। एक नंबर जिसकी गणना दिखाई गई है एक अकेले कुल से कहीं अधिक भरोसेमंद है।
यह कहाँ जुड़ता है
कैश काउंटर सेटअप में मध्य परत है। एक बार जब यह काम कर जाता है, तो प्रति सीट लागत अनुमानित हो जाती है और आप प्रति-सीट तुलना के साथ इसके आसपास एक प्लान कीमत निर्धारित कर सकते हैं। छोटी पेजों को एक स्पष्ट अंत चाहिए। इसका है।
कोड रिव्यू में हमें जो कैश सवाल मिलते हैं
क्या कैश ब्राउज़र में भी रहना चाहिए?
एक छोटा ब्राउज़र कैश बैक-बटन नेविगेशन में मदद करता है, लेकिन आपके सर्वर पर साझा कैश असली बचत करता है। क्लाइंट-साइड स्टोरेज को मिनटों तक रखें, क्योंकि अलग-अलग मशीनों पर उपयोगकर्ता एक ही दिन पर एक ही डोमेन के लिए अलग-अलग नंबर देखेंगे।
यदि एक ग्राहक कहता है कि एक नया लिंक गायब है तो क्या करें?
अपने UI में दिखाए गए इंडेक्स माह की जाँच करें। यदि लिंक पिछले रिफ्रेश के बाद जोड़ा गया था, तो यह अगले में दिखाई देगा। एक नोट पेश करें, न कि रिफंड, क्योंकि कुछ भी टूटा नहीं है।
क्या मैं मांग पर कैश को छोड़ सकता हूँ?
आप कर सकते हैं, लेकिन प्रत्येक बायपास क्रेडिट की लागत करता है एक ऐसे उत्तर के लिए जो संभवतः समान है। इसे केवल एडमिन्स को पेश करें, और एक्सीडेंटल लूप से बचने के लिए प्रति वर्कस्पेस इसे रेट-लिमिट करें।
पेजिनेशन और कैश कुंजी
पेजिनेशन हर किसी को एक बार काटती है। इसे कुंजी में शामिल करें।
backlinks और refdomains क्रियाएं प्रति कॉल 1,000 पंक्तियां तक लौटाती हैं, page और per 10 और 5000 के बीच, और गहरी पेजिंग 50,000 पंक्तियों तक सीमित है, इसलिए उन पैरामीटर के बिना एक कुंजी हर अनुरोध के लिए पेज एक सेवा करेगी।
सॉर्टिंग भी कुंजी में होनी चाहिए। एक उपयोगकर्ता जो DR अवरोही से वर्णमाला में बदलता है एक अलग सूची की उम्मीद करता है, और कैश को पूरे सेट को स्टोर करने के बाद बिना एक नए अपस्ट्रीम कॉल के ऐसा करना चाहिए।
एक तेज़ टेस्ट अधिकांश कुंजी त्रुटियों को पकड़ता है। पेज दो अनुरोध करें, सॉर्ट बदलें, फिर जांचें कि कैश किया गया पेज दो कैश किए गए पेज एक से अलग है। यदि ऐसा नहीं है, तो कुंजी में एक पैरामीटर गायब है। जल्दी पाया गया, इसकी लागत मिनट है। एक ग्राहक इसे कभी नहीं देखता। प्रत्येक रिलीज़ से पहले टेस्ट को फिर से चलाएं, क्योंकि एक नया सॉर्ट विकल्प आमतौर पर कुंजी को तोड़ने का कारण होता है। इसे अपनी रिलीज चेकलिस्ट में लिखें।
एक्सपोर्ट बटन की अलग से योजना बनाएं: एक बैकग्राउंड जॉब, एक स्टोर्ड फ़ाइल, और एक नोटिफिकेशन जब यह तैयार हो।
