URL बैकलिंक चेकर को बिना किसी गैप या लूप के पेज करें
हर कॉल के लिए पंक्तियों की संख्या, हर क्वेरी के लिए पेजों की संख्या और 50,000 की कड़ी सीमा। यहाँ एक लूप है जो इन तीनों का सम्मान करता है और बताता है कि कब रुकना है।
हर कॉल में 1,000 पंक्तियाँ तक वापस आती हैं। हर कॉल को एक बार बिल किया जाता है, चाहे उसमें कितनी भी पंक्तियाँ हों। डीप पेजिनेशन 50,000 पंक्तियों तक सीमित है, जो 1,000 पंक्तियों वाली 50 कॉल्स के बराबर है।
पेजिनेशन से पहले सॉर्टिंग क्यों जरूरी है
बिना सॉर्ट की गई सूची पर पेजिनेशन डुप्लिकेट्स का कारण बनती है। हमेशा sort और order को page और per के साथ भेजें, ताकि रन के हर रिक्वेस्ट में पेज 3 का मतलब वही रहे।
एक refdomains पुल में 2 क्रेडिट्स की लागत आती है, इसलिए 50 कॉल्स की कुल लागत 100 क्रेडिट्स या एक सेंट आती है। सबसे बुरा मामला भी सस्ता है; असली लागत एक ऐसे लूप की है जो समाप्त नहीं होता।
सॉर्ट कॉलम चुनना
किस कॉलम पर सॉर्ट करना है, यह सवाल पर निर्भर करता है। ऑडिट के लिए सबसे बड़ा मान पहले रखना आम तौर पर बेहतर होता है, क्योंकि इससे कैप लंबी लिस्ट के अंत को काट देता है, न कि उस हिस्से को जिसमें आपकी रुचि है।
ऐसे फील्ड पर सॉर्ट करें जिसका आपके सवाल से कोई लेना-देना न हो, और कटऑफ उन पंक्तियों को हटा सकता है जिन्हें आप चाहते थे। पहले प्रत्येक उम्मीदवार के लिए दस पंक्तियाँ खींचें और देखें कि कैप के बाद कौन सा हिस्सा बचता है।
अपनी चुनिंदा सॉर्टिंग को रिपोर्ट में लिखें, ताकि अगली बार यह पता चले कि कटऑफ क्यों और कहाँ लगाया गया।
रन के दौरान बदलने वाली रिकॉर्ड्स
रिकॉर्ड्स रन के दौरान तब तक नहीं बदलते जब तक कि मासिक रीबिल्ड मध्य में न आ जाए। यह दुर्लभ है, लेकिन असली है। एक नॉक्टाल जॉब जो महीने की पहली तारीख के आसपास चलती है, एक पेज पुराने इंडेक्स से और अगला नए इंडेक्स से दे सकती है, इसलिए अपने लॉग में स्टार्ट टाइम रिकॉर्ड करें और तुलना करें।
लॉग के शीर्ष पर स्टार्ट टाइम और हर लाइन पर पेज नंबर लिखें। फिर आउटपुट में कोई असंगति टाइमिंग की ओर इशारा करेगी, न कि किसी पार्सिंग बग की ओर।
यदि जॉब शेड्यूल है, तो संभावित रीबिल्ड से ठीक पहले स्टार्ट टाइम से बचें। आपके लॉग रीबिल्ड को दो रनों के बीच कुल योग में बदलाव के रूप में दिखाते हैं, इसलिए हर लॉग लाइन में कुल योग रखें।
एक रीबिल्ड को पार करने वाला रन डिफ़ॉल्ट रूप से गलत नहीं है। यह केवल असंगत है, इसलिए उन रनों को लॉग में मार्क करें और जब रिपोर्ट के लिए महत्वपूर्ण हो तो प्रभावित स्लाइस को फिर से चलाएं।
एक पेजिंग लूप जो रुकता है
Node 20 वर्कर के लिए TypeScript। यह पहले छोटे पेज पर, कैप पर, या किसी भी ok जो सत्य नहीं है, पर रुक जाता है।
const BASE = "https://seomasters.dev/api.php";
const CAP = 50_000;
const PER = 1000;
export async function pullAll(domain: string, key: string) {
const rows: unknown[] = [];
for (let page = 1; rows.length < CAP; page++) {
const u = new URL(BASE);
u.search = new URLSearchParams({
action: "refdomains", q: domain,
page: String(page), per: String(PER),
sort: "dr", order: "desc",
}).toString();
const res = await fetch(u, { headers: { Authorization: `Bearer ${key}` } });
if (res.status === 401 || res.status === 402) throw new Error(`stop: HTTP ${res.status}`);
const body = await res.json();
if (!body.ok) throw new Error(JSON.stringify(body).slice(0, 300));
const chunk = findRows(body); // see note below
rows.push(...chunk);
if (chunk.length < PER) break; // short page means we are done
}
return rows;
}पेजिंग रन की समस्या निवारण
| आप क्या देख रहे हैं | संभावित कारण | क्या करना है |
|---|---|---|
| पेज 51 खाली या त्रुटि के साथ आता है | आपने 50,000 की कैप को छू लिया है | किसी अन्य एक्शन या अलग sort से संकीर्ण करें, फिर id से मर्ज करें |
| दो पेजों पर एक ही डोमेन | बिना सॉर्ट की गई क्वेरी, या इंडेक्स रन के बीच रीबिल्ड हो गया | sort और order भेजें; डोमेन की ओर से डुप्लिकेट हटाएं |
| डैशबोर्ड के कुल योग से कम पंक्तियाँ | कुल योग पूरे ग्राफ के लिए है, पुल कैप किया गया है | UI में "टॉप 50,000" दिखाएं |
| लूप कभी समाप्त नहीं होता | कंडीशन चेक केवल rows.length करती है | एक छोटे पेज पर ब्रेक लगाएं, जैसा ऊपर बताया गया है |
| अपेक्षित से अधिक बिल | हर गैर-200 पर रीट्राई करें | केवल नेटवर्क फॉल्ट्स पर रीट्राई करें, त्रुटियां देखें |
फील्ड नामों की अनुमान लगाए बिना पंक्तियाँ पढ़ना
ऊपर दिया गया findRows हेल्पर जानबूझकर खुला छोड़ा गया है। एक असली कॉल करें, JSON देखें और ट्यूटोरियल द्वारा वादे किए गए फील्ड्स के बजाय जो कुछ आप देखते हैं, उसके खिलाफ एक्सेसर लिखें।
इस जॉब के सस्ते रिश्तेदार के लिए, बिना किसी पेजिंग के एक साथ कई डोमेन का स्कोरिंग करने के लिए, बल्क DR स्क्रिप्ट पढ़ें।
एक रिस्पॉन्स को फिक्स्चर के रूप में फ्रीज करें
फिर इसे टेस्ट के साथ फ्रीज करें। एक रिस्पॉन्स को फिक्स्चर फाइल के रूप में सेव करें और भविष्य में बदलाव को ग्राहक के चार्ट में नहीं, बल्कि CI में फेल होने दें, इसलिए पंक्तियों की संख्या और पहली पंक्ति के कीज़ पर एसेर्ट करें।
फिक्स्चर को टेस्ट के साथ ही वर्जन कंट्रोल में रखें, ताकि रिव्यूअर बिना कुछ चलाए यह देख सके कि कोड किस आकार की उम्मीद कर रहा है।
जब API बाद में कोई फ़ील्ड जोड़ता है, तो फ़िक्स्चर डिफ़ आपको बताता है कि आपके एक्सेसर ने उसे नोटिस किया या चुपचाप अनदेखा किया।
फ़िक्स्चर का नाम उस क्वेरी के अनुसार रखें जिससे वह आया था, जैसे कि एक्शन, डोमेन और सॉर्ट। response1.json नाम की एक फ़ाइल अगले पाठक को यह नहीं बताती कि वह क्या साबित करती है।
आपने जितनी पंक्तियाँ स्टोर की हैं, उनका गिनती करें
अपने द्वारा सेव की गई पंक्तियों की तुलना लूप द्वारा रिपोर्ट किए गए कुल से करें। एक अंतर का मतलब है कि एक पेज छोड़ दिया गया, और एक दोहराव का मतलब है कि एक पेज दो बार फ़ेच किया गया और एक पंक्ति में अपसर्ट किया गया।
हर टेस्ट पुल के बाद वह चेक चलाएं, न कि केवल पहले के बाद। गिनती में बदलाव आमतौर पर बदले हुए सॉर्ट या रन के बीच में होने वाले रीबिल्ड का पहला लक्षण होता है।
गिनती को पेज नंबर के साथ एक ही लॉग लाइन में रखें, ताकि दोनों को एक नज़र में पढ़ा जा सके।
छत से ऊपर काम को बांटना
कुछ सवाल छत से बड़े हो जाते हैं। छत से ऊपर की लिस्ट्स के लिए, कठोरता से पेजिंग करने के बजाय समस्या को बांटें। एक सॉर्ट द्वारा शीर्ष 50,000 खींचें, फिर भारी हिटर्स के बारे में अन्य एक्शन्स से पूछें, क्योंकि उन पर 2 क्रेडिट्स भी खर्च होते हैं और वे अलग सवालों के जवाब देते हैं। कठोरता से पेजिंग करने से कटऑफ़ से कभी नहीं पार किया जा सकता।
एक सॉर्ट द्वारा शीर्ष 50,000 खींचें
API की छत को एक तथ्य के रूप में लें। एक सॉर्ट द्वारा शीर्ष 50,000 पंक्तियाँ खींचें, उन्हें स्टोर करें और किसी भी रिपोर्ट में परिणाम को टॉप स्लाइस के रूप में लेबल करें।
एक डैशबोर्ड जो कैप्ड काउंट को पूरे कुल की तरह दिखाता है, उसे पढ़ने वालों को भ्रमित करता है। लेबल का कोई खर्च नहीं है, और एक url backlink checker रिपोर्ट इसके साथ अधिक ईमानदार लगती है।
रन से पहले स्लाइस साइज तय करें और रिपोर्ट हेडर में लिखें, ताकि संख्या कभी भी वास्तविकता से बड़ी न दिखे। एक हेडर लाइन का कोई खर्च नहीं है, और एक पाठक जो बाद में एक खोई हुई पंक्ति पाता है, उसके लिए आपका धन्यवाद करेगा।
भारी हिटर्स से एक अलग सवाल पूछें
anchors और toppages अन्य सवालों के जवाब देते हैं, जैसे कि कौन सा एंकर टेक्स्ट हावी है या कौन से पेज लिंक्स आकर्षित करते हैं। एक डोमेन के लिए जो छत से परे है, वे जवाब उसी लिस्ट के अगले पेज से अधिक मायने रख सकते हैं।
उनके परिणामों को डोमेन द्वारा कुंजीबद्ध अपने अलग टेबल्स में रखें, ताकि उसी डोमेन का एक बाद का पुल टॉप-स्लाइस पंक्तियों को बिना छुए उन्हें बदल सके।
प्रत्येक अतिरिक्त एक्शन का अपना खर्च होता है, इसलिए बिल आने के बाद नहीं, बल्कि रन से पहले इसकी कीमत तय करें।
सबसे भारी डोमेन की एक छोटी लिस्ट, जिसे महीने में एक बार खींचा जाता है, अक्सर हर रात खींची गई एक लंबी लिस्ट की तुलना में अधिक उपयोगी संदर्भ देती है।
डोमेन कुंजी पर मर्ज करें
जब दो पुल ओवरलैप होते हैं, तो उन्हें डोमेन कुंजी पर मर्ज करें और नए टाइमस्टैम्प को रखें। मर्ज तब कभी इस बात पर निर्भर नहीं करता कि कौन सा पुल पहले समाप्त हुआ।
लॉग करें कि प्रत्येक पंक्ति के लिए कौन सा पुल जीता। यदि एक संख्या दो रिपोर्ट्स के बीच बदल जाती है, तो वह लॉग आपको बताता है कि इंडेक्स या मर्ज बदला है।
मर्ज को एक ही फ़ंक्शन में एक टेस्ट के साथ रखें, क्योंकि यह वह एकमात्र जगह है जहाँ दो मिलते हैं।
क्रैश के बाद फिर से शुरू करना
क्रैश होते हैं। एक डिप्लॉय वर्कर को रीस्टार्ट करता है, एक लैपटॉप स्लीप मोड में चला जाता है, एक VPN ड्रॉप हो जाता है, और लूप 50 में से पेज 31 पर मर जाता है।
हर कॉल के बाद पेज सेव करें
हर कॉल के बाद आखिरी पूरी पेज नंबर को पर्सिस्ट करें। उस नंबर प्लस वन से रीस्टार्ट करें, न कि शीर्ष से, और आप पेज प्रति 2 क्रेडिट्स के लिए भुगतान करते हैं, पूरे पुल को फिर से खरीदने के बजाय।
इसे रिस्पॉन्स के पार्स होने के बाद सेव करें, पहले नहीं। एक पेज जिसे आपने पढ़ने में विफल रहे, उसे फिर से फ़ेच किया जाना चाहिए, और एक सेव किया गया पेज नंबर हमेशा उन पंक्तियों का मतलब देना चाहिए जो आपके पास हैं।
एक सेव जो हर कॉल के बजाय प्रति मिनट एक बार होता है, एक खिड़की छोड़ देता है जहाँ क्रैश क्रेडिट खर्च को दोहरा सकता है। लिखना छोटा रखें, ताकि हर बार करना सस्ता हो।
प्रत्येक सेव में कितना समय लगता है और प्रत्येक कॉल में कितना समय लगता है, दोनों को लॉग करें। एक सेव जो कॉल के बराबर समय लेता है, स्टोरेज लेयर की ओर इशारा करता है, और लूप के बढ़ने से पहले उसे ठीक करना मूल्यवान है।
डोमेन कुंजी पर अपसर्ट करें
एक आइडेंपोटेंट लिख रखें। प्रत्येक पंक्ति को उसकी डोमेन कुंजी पर अपसर्ट करें, ताकि दो बार फ़ेच किया गया पेज दो पंक्तियों के बजाय एक पंक्ति छोड़ दे।
हर लिख पाथ पर एक ही कुंजी का उपयोग करें, मैन्युअल रिपेयर स्क्रिप्ट सहित। दो लिख पाथ्स के साथ दो कुंजियाँ इस बात का कारण बनती हैं कि डुप्लिकेट्स एक रिज्यूम में जीवित रहते हैं।
एक रिपेयर स्क्रिप्ट अक्सर एक विफल रन के बाद जल्दी में लिखा जाता है। तभी एक दूसरी कुंजी घुस जाती है, इसलिए इसे मुख्य लूप की तरह ही सावधानी से समीक्षा करें।
जब सॉर्ट बदल जाए तो रिज्यूम को अस्वीकार करें
पेज नंबर के साथ सॉर्ट और ऑर्डर को लॉग करें। यदि कोई व्यक्ति क्रैश और रीस्टार्ट के बीच sort बदल देता है, तो सेव किया गया पेज नंबर उसी स्लाइस का मतलब नहीं देता। रिज्यूम को अस्वीकार करें और साफ़ शुरू करें।
सॉर्ट, ऑर्डर, पेज और समय के साथ एक छोटा रिज्यूम रिकॉर्ड स्टोर करें। लूप उस रिकॉर्ड को पहले पढ़ता है, और यह अस्वीकार कर देता है यदि कोई भी फ़ील्ड अब उस अनुरोध से मेल नहीं खाता जिसके बारे में वह अगला कदम उठाने वाला है।
एक अस्वीकृत रिज्यूम कोई विफलता नहीं है। यह लूप द्वारा कहा गया है कि सेव किया गया पेज अब उसी पंक्तियों का मतलब नहीं देता, और साफ़ शुरू करना सस्ता गलती है।
प्रोडक्शन में लूप चलाना
- 1
एक छोटे डोमेन से शुरू करें
कुछ सौ पंक्तियों वाले एक डोमेन के खिलाफ लूप चलाएं, ताकि शॉर्ट-पेज स्टॉप फायर हो और आप एग्जिट पाथ को काम करते हुए देखें।
- 2
एक पेज को आँखों से जांचें
एक स्टोर किए गए रिस्पॉन्स को खोलें और पुष्टि करें कि एक्सेसर अभी भी पंक्तियों को पढ़ रहा है। उस पार्स पर भरोसा न करें जिसके बारे में आपने देखा नहीं है।
- 3
लिमिट्स को कॉन्फ़िग में रखें
छत और पेज साइज को एक ही कॉन्फ़िग फ़ाइल में डालें, ताकि एक बदलाव रिव्यू में दिखाई दे और एक फ़ंक्शन के अंदर छिपे नहीं।
- 4
लूप के समाप्त होने का कारण लॉग करें
रन को एक शॉर्ट पेज पर, छत पर या एक त्रुटि पर समाप्त होने के बारे में रिकॉर्ड करें। वे तीन अंत उन लोगों के लिए अलग-अलग अर्थ रखते हैं जो लॉग पढ़ते हैं।
