रेट लिमिट का सम्मान कैसे करें: API और वेब रिक्वेस्ट का पेसिंग
Scrapeless Web Unlocker सार्वजनिक URLs से कॉन्टेंट प्राप्त करता है ताकि आपका एप्लिकेशन अलग से नियंत्रित रिक्वेस्ट बजट के भीतर रिस्पॉन्स को पार्स कर सके।
सारांश
- रेट लिमिट प्रोवाइडर के काउंटिंग स्कोप पर लागू होती हैं। कई वर्कर एक ही अकाउंट या endpoint allowance को उपयोग कर सकते हैं।
- Concurrency और रिक्वेस्ट रेट अलग‑अलग चीजों को मापते हैं। सक्रिय कार्य और नई रिक्वेस्ट शुरू होने दोनों को सीमित करें।
- कुशल कलेक्शन डिस्पैच से पहले ही डिमांड को कम कर देता है। डुप्लिकेट URLs हटाएँ, मान्य कैश्ड डेटा को पुन: उपयोग करें, और केवल ज़रूरी पेज ही रिक्वेस्ट करें।
- एक सीमित जॉब को एक स्पष्ट अधूरा (incomplete) स्टेट की ज़रूरत होती है। एक ब्लॉक्ड कलेक्शन को कभी भी एक पूर्ण डेटासेट के रूप में रिकॉर्ड नहीं किया जाना चाहिए।
किसी लिमिट का सम्मान पहली रिक्वेस्ट से पहले ही शुरू हो जाता है
रेट लिमिट का सम्मान करने का मतलब है कि रिक्वेस्ट गतिविधि को सेवा की प्रलेखित अलाउंस, उसकी काउंटिंग रूल्स और बर्स्ट बाधाओं के भीतर रखना। कोई कलेक्टर जो लिमिट पर पहुँचने के बाद विनम्र व्यवहार करता है, वह पहले ही इरादे से अधिक क्षमता इस्तेमाल कर चुका होता है। नेटवर्क डिस्पैच से पहले admission control बनाएं: काम एक कतार (queue) में आता है, शेड्यूलर लागू बजट की जाँच करता है, और केवल अनुमत काम ही शुरू होता है। यह तरीका रिक्वेस्ट प्लान को ट्रैफिक पैदा होने से पहले ही समीक्षा‑योग्य बना देता है।
जिस सटीक संसाधन का आप उपयोग कर रहे हैं, उसके लिए प्रोवाइडर की पॉलिसी पढ़ें। एक लिमिट अकाउंट, API key, यूज़र, IP एड्रेस, किसी route या इनका संयोजन—किसी पर भी लागू हो सकती है। Search और export endpoints पर अलग‑अलग प्रतिबंध हो सकते हैं। एक दैनिक अलाउंस के साथ एक छोटी rolling window भी मौजूद हो सकती है। किसी undocumented काउंटर को अज्ञात मानें, न कि यह मान कर कि किसी अन्य endpoint की पॉलिसी उसे भी कवर करती है।
The HTTP 429 status definition एक रिक्वेस्ट वॉल्यूम लिमिट की पहचान करता है, लेकिन यह मानकीकृत नहीं करता कि हर सेवा कॉलर को कैसे पहचाने या रिक्वेस्ट्स को कैसे गिने। इसलिए एक error page पूरी पॉलिसी स्थापित नहीं कर सकता। प्रकाशित दस्तावेज़ और अपने अकाउंट कॉन्फ़िगरेशन को जॉब सेटिंग्स के साथ रखें, और ऐसा ओनर असाइन करें जो बड़ी कलेक्शन शुरू होने से पहले अस्पष्ट कोटा स्पष्ट कर सके।
पॉलिसी को एक साझा बजट में अनुवाद करें
एक shared budget स्वतंत्र वर्करों को एक ही अलाउंस को अलग‑अलग तरीके से खर्च करने से रोकता है। मान लें कोई काल्पनिक अकाउंट प्रति मिनट साठ नई रिक्वेस्ट की अनुमति देता है, जबकि तीनों प्रोसेस में से हर एक मानता है कि उसके पास अपने साठ हैं। हर प्रोसेस स्थानीय रूप से compliant दिख सकता है, जबकि अकाउंट अपने कुल अलाउंस से ऊपर चला जाता है। समाधान है उस अकाउंट और पॉलिसी window से संबंधित सभी कार्य के लिए एक ही admission निर्णय रखना।
काल्पनिक संख्या का उपयोग केवल अंकगणित समझने के लिए करें; यह Scrapeless का कोटा या अनुशंसित ऑपरेटिंग रेट नहीं है। इंटरैक्टिव उपयोग, मॉनिटरिंग कॉल्स और अकाउंट साझा करने वाले अन्य एप्लिकेशनों के लिए जगह आरक्षित रखें। यदि उन उपभोक्ताओं को मापा नहीं जा सकता, तो कलेक्टर का आवंटन संयमित रखें और अनिश्चितता को दस्तावेज़ करें। प्रदाता की सख्त सीमा को उस कम मात्रा से अलग रखें जिसे आपका जॉब उपभोग करने की अनुमति रखता है।
उस इकाई को ट्रैक करें जिसके विरुद्ध प्रोवाइडर वास्तव में लिमिट चार्ज करता है। कुछ पॉलिसियाँ रिक्वेस्ट गिनती हैं; अन्य records, processing units, bytes या ऑपरेशन की जटिलता गिनती हैं। एक बैच जिसमें बहुत‑सी ऑपरेशन्स हों, वह फिर भी पर्याप्त क्षमता खपा सकता है। प्रत्येक queue आइटम के साथ बजट स्कोप और लागत मॉडल रिकॉर्ड करें ताकि कोई महँगा export ऐसे admit न हो जाए मानो वह हल्का‑फुल्का metadata lookup हो।
रिक्वेस्ट स्टार्ट और सक्रिय कार्य को अलग‑अलग नियंत्रित करें
रिक्वेस्ट पेसिंग नियंत्रित करती है कि नया काम कितनी बार शुरू होता है; concurrency नियंत्रित करती है कि एक समय में कितना काम सक्रिय रहता है। केवल concurrency cap रिक्वेस्ट रेट लागू नहीं कर सकती, क्योंकि तेज़ रिस्पॉन्स worker को एक ही window के भीतर कई ऑपरेशन शुरू करने देता है। केवल start‑rate cap मेमोरी की रक्षा नहीं कर सकता जब रिस्पॉन्स बड़े या धीमे हो जाएँ। दोनों नियंत्रणों को एक ही dispatcher के आसपास उपयोग करें।
ब्राउज़र जॉब्स को एक अतिरिक्त भेद की ज़रूरत होती है। एक पेज खोलने से document, script, image और background API रिक्वेस्ट हो सकती हैं। एक single navigation अनिवार्य रूप से एक origin रिक्वेस्ट नहीं है। ब्राउज़र ऑटोमेशन कमांड्स की गिनती से compliance का दावा करने से बचें। सार्वजनिक डेटा वर्कफ़्लो के लिए, समझें कि कौन‑सी क्रियाएँ नेटवर्क activity शुरू करती हैं और टास्क को जिन पेज और interactions की वास्तव में ज़रूरत है, उन्हें सीमित करें।
queue क्षमता के साथ‑साथ worker क्षमता भी सेट करें। एक unbounded backlog छोटी ट्रैफिक स्पाइक को घंटों के बासी काम में बदल देता है। टास्क को expiry time और स्पष्ट प्राथमिकता दें। जो प्राइस ऑब्ज़र्वेशन अपनी रिपोर्टिंग window के बाद पहुँचती है, वह शायद अब उपयोगी न हो। भेजे न गए पुराने काम को जानबूझकर हटा दें, और उस निर्णय को रिकॉर्ड करें ताकि downstream उपभोक्ता freshness limits और missing records के बीच अंतर कर सकें।
| नियंत्रण | यह क्या सीमित करता है | यह किस चीज़ को साबित नहीं करता |
|---|---|---|
| Start-rate budget | किसी पॉलिसी window के दौरान नई ऑपरेशन्स | कि महँगी और सस्ती ऑपरेशन्स की लागत समान है |
| Concurrency cap | वह ऑपरेशन्स जो वर्तमान में प्रगति पर हैं | कि रिक्वेस्ट स्टार्ट किसी window लिमिट से नीचे ही रहते हैं |
| Queue bound | अनसेंट काम और प्रतीक्षा समय | कि पूर्ण हुआ डेटासेट हर अपेक्षित रिकॉर्ड रखता है |
| Spending cap | जॉब के लिए वित्तीय exposure | कि कोई target वेबसाइट उस ट्रैफ़िक की अनुमति देती है |
क्षमता बढ़ाने से पहले माँग घटाएँ
अनावश्यक रिक्वेस्ट घटाने से वह क्षमता बचती है जिसकी जॉब को सच में ज़रूरत वाली जानकारी के लिए आवश्यकता होती है। लक्ष्य URLs को सावधानी से normalize करें, डुप्लिकेट टास्क हटाएँ, और केवल वहीं पुन: उपयोग योग्य परिणाम cache करें जहाँ संसाधन की पॉलिसी इसकी इजाज़त देती है। अलग‑अलग query strings अलग कॉन्टेंट दर्शा सकती हैं, इसलिए normalization को सार्थक फ़िल्टर और page state को बनाए रखना चाहिए। Deduplication जो अलग‑अलग संसाधनों को मिला देती है, वह कॉल्स बचाती है लेकिन डेटा गुणवत्ता की कीमत पर।
HTTP cache controls यह निर्धारित करें कि किसी प्रतिक्रिया को HTTP कैश द्वारा संग्रहीत किया जा सकता है और पुन: उपयोग किया जा सकता है या नहीं। एक स्थानीय एप्लिकेशन कैश को भी एक ताजगी नियम की आवश्यकता होती है: यह तय करें कि व्यावसायिक कार्य के लिए कोई मान कितना पुराना हो सकता है। एक कैटलॉग विवरण और एक लाइव स्टॉक अवलोकन की ताजगी आवश्यकताएँ अलग‑अलग होती हैं। अवलोकन समय को मान के साथ-साथ संग्रहीत करें, बजाय इसके कि कैश की गई सामग्री को चुपचाप वर्तमान के रूप में प्रस्तुत किया जाए।जब वर्कफ़्लो इसकी अनुमति दे, तो बार‑बार जांच करने के बजाय स्रोत‑समर्थित सूचनाओं का उपयोग करें। The GitHub REST उपयोग प्रथाएँ दिखाती हैं कि सशर्त अनुरोध और ईवेंट डिलीवरी अनावश्यक पोलिंग को कैसे कम कर सकते हैं। ये एक प्रदाता के अनुबंध के उदाहरण हैं, कोटा लेखांकन से सार्वभौमिक अपवाद नहीं। यह सुनिश्चित करें कि आपका चुना हुआ सेवा प्रदाता सशर्त प्रतिक्रियाओं और अधिसूचना के फॉलो‑अप कॉल्स को कैसे गिनता है।
पेजिनेशन को उसी अलाउंस के अंदर रखें
पेजिनेशन अनुरोध बजट का हिस्सा है, जिनमें वे पेज भी शामिल हैं जो कोई उपयोगी नए रिकॉर्ड नहीं लौटाते। लॉन्च से पहले आवश्यक ट्रैवर्सल का अनुमान लगाएँ और प्रलेखित एंड मार्कर पर रुक जाएँ। गलत टर्मिनेशन नियम के कारण अंतिम पेज को बार‑बार अनुरोध करना क्षमता का उपभोग करता है बिना कवरेज में सुधार किए। क्वेरी के साथ‑साथ कंटिन्यूएशन स्टेट को संग्रहीत करें ताकि अगला कदम उसी रिजल्ट सेट परिभाषा का पालन करे।
पेज साइज ऑपरेशन की गिनती और प्रतिक्रिया लागत के बीच के संतुलन को बदल देता है। बड़े पेज राउंड ट्रिप्स को कम कर सकते हैं, लेकिन वे मेमोरी उपयोग, प्रोसेसिंग समय और सेवा वर्कलोड को बढ़ा सकते हैं। एक समर्थित साइज चुनें जो कार्य के अनुकूल हो, बजाय इसके कि प्रदाता के अधिकतम को डिफ़ॉल्ट मान लें। एक छोटी प्रतिनिधि कलेक्शन दिखा सकती है कि पार्सिंग या स्टोरेज सीमित करने वाला चरण बनता है या नहीं।
केवल तब ही चेकपॉइंट करें जब पेज के रिकॉर्ड अपने गंतव्य पर कमिट हो चुके हों। यदि स्टोरेज पूरा होने से पहले कंटिन्यूएशन स्टेट आगे बढ़ जाता है, तो डेटासेट में एक मौन गैप हो सकता है। एक उपयोगी चेकपॉइंट में क्वेरी फ़िंगरप्रिंट, स्वीकार किए गए रिकॉर्ड की गिनती, कंप्लीशन मार्कर और कैप्चर समय शामिल होता है। क्रेडेंशियल्स को चेकपॉइंट फ़ाइलों से बाहर रखें और यदि प्रदाता उन्हें संवेदनशील मानता है तो अपारदर्शी कंटिन्यूएशन मानों को रिडैक्ट करें।
जॉब ओनर के लिए लिमिट प्रतिक्रियाएँ दृश्यमान बनाएं
एक लिमिट प्रतिक्रिया को प्रभावित स्कोप के भीतर नए डिस्पैच को रोक देना चाहिए और जॉब को एक स्पष्ट अवस्था में छोड़ देना चाहिए। निदान के लिए स्टेटस, स्वच्छ (sanitized) प्रतिक्रिया विवरण और पॉलिसी पहचानकर्ता को संरक्षित रखें। जब सर्वर वास्तव में अनुरोध को अस्वीकार कर दे, तब खाली परिणाम को सफल संग्रह के रूप में चिह्नित न करें। उपभोक्ताओं को यह जानने की ज़रूरत है कि रिकॉर्ड मौजूद नहीं थे या जॉब उन्हें प्राप्त नहीं कर पाया।
अथॉराइज़ेशन, कोटा, वेलिडेशन और उपलब्धता की विफलताओं को अलग‑अलग रखें। एक forbidden प्रतिक्रिया एक अनुमति निर्णय का प्रतिनिधित्व कर सकती है। एक गलत संरचित (malformed) अनुरोध काम की खपत कर सकता है बिना कभी मान्य बने। वही HTTP स्टेटस प्रदाता‑विशिष्ट त्रुटि विवरण ले जा सकता है, इसलिए घटना को वर्गीकृत करने से पहले प्रलेखित प्रतिक्रिया बॉडी को पढ़ें। जॉब्स को अनसुलझा छोड़ें ताकि उनके ओनर के पास शेड्यूलिंग निर्णय लेने के लिए आवश्यक सबूत हों।
ऑपरेशनल रिपोर्टिंग में स्वीकृत कार्य, पूर्ण कार्य, स्थगित असेंड (unsent) कार्य और अस्वीकृत कार्य शामिल होना चाहिए। इन्हें स्टोर किए गए रिकॉर्ड्स और स्रोत के कंप्लीशन सिग्नल के साथ तुलना करें। ऐसा डैशबोर्ड जो केवल सफल कॉल्स दिखाता है, उस मांग को छुपा देता है जिसने कभी डेटा उत्पन्न नहीं किया। प्रेक्षणों को खाते और एंडपॉइंट स्कोप के अनुसार समूहित रखें; सब कुछ एक प्रतिशत में समेट देना उस सटीक बजट को छुपा सकता है जिसने रन को सीमित किया।
इन नियंत्रणों को Scrapeless के आसपास लागू करें
आपका शेड्यूलर उस कलेक्शन के अधिकृत स्कोप और गति के लिए ज़िम्मेदार रहता है जो Scrapeless Web Unlockerका उपयोग करता है। यह उत्पाद कंटेंट को पुनर्प्राप्त करता है; आपकी एप्लिकेशन तय करती है कि किन URLs की आवश्यकता है, कौन सा आउटपुट स्वीकार्य है, और जॉब जारी रहना चाहिए या नहीं। प्रदाता खाते की उपयोग सीमाओं को लक्षित साइट के एक्सेस नियमों और आपकी अपनी रिपोर्टिंग डेडलाइन से अलग रखें।
का उपयोग करें Web Unlocker request capabilities अपने कार्य के लिए आवश्यक प्रतिक्रिया हैंडलिंग चुनने के लिए, फिर लागू बिलिंग मॉडल के लिए Scrapeless pricing की समीक्षा करें। यह लेख किसी उत्पाद कोटा असाइन नहीं करता या यह वादा नहीं करता कि प्रबंधित एक्सेस रेट लिमिट्स को हटा देता है। एक सर्विस प्लान और लक्ष्य की परमिशन सीमा अलग‑अलग प्रश्नों का उत्तर देते हैं और दोनों का कलेक्शन डिज़ाइन में होना ज़रूरी है।
एक रिव्यू योग्य कलेक्शन प्लान
एक रिव्यू योग्य प्लान ट्रैफ़िक शुरू होने से पहले डेटासेट, अनुमत स्रोत, समय विंडो और स्टॉपिंग नियमों का वर्णन करता है। अपेक्षित पेज ट्रैवर्सल, साझा अकाउंट उपभोक्ता, कैश ताजगी, कतार की समाप्ति (queue expiry) और रिकॉर्ड‑स्तर की स्वीकार्यता मानदंड शामिल करें। प्लान को इतना विशिष्ट बनाएं कि कोई अन्य इंजीनियर कलेक्टर के इम्प्लीमेंटेशन को पढ़े बिना यह बता सके कि परिणाम पूरा है या नहीं।
उदाहरण के लिए, एक काल्पनिक कैटलॉग ऑडिट को एक स्वीकृत श्रेणी और नामित रिपोर्टिंग अवधि तक सीमित किया जा सकता है। इसका कंप्लीशन नियम प्रलेखित अंतिम पेज है, साथ ही प्रत्येक स्वीकृत रिकॉर्ड के लिए कमिटेड स्टोरेज। इसकी स्टॉप कंडीशन्स में समाप्त अलोकेशन, परमिशन विफलता और समाप्त टास्क प्रासंगिकता शामिल हैं। यह डिज़ाइन ऐसा उपयोगी आंशिक रिपोर्ट बनाता है जब जॉब पूरा नहीं हो पाता, बजाय एक ऐसे दिखने में सफल फ़ाइल के जिसकी कवरेज समझाई नहीं जा सकती।
निष्कर्ष
डेटा इकट्ठा करने से पहले अनुरोध बजट की योजना बनाएं, उस बजट को वर्कर्स में साझा करें, और डेटासेट सीमा पर कंप्लीशन को मापें। कुशल पेजिनेशन, कैश नियम, सीमित कतारें और स्पष्ट स्टॉप स्टेट्स कलेक्शन को चलाना और समझाना आसान बनाते हैं। जब क्षमता अपर्याप्त हो, तो स्कोप को कम करें या आगे का काम शेड्यूल करने से पहले उपयुक्त अलाउंस प्राप्त करें।
अपना वेब डेटा वर्कफ़्लो बनाएं
URL‑आधारित कंटेंट रिट्रीवल के लिए Web Unlocker का उपयोग करें जबकि आपकी एप्लिकेशन स्कोप, पेसिंग और डेटा स्वीकृति को नियंत्रित करती है।
आज ही साइन अप करें और पाएं $5 in free credit — कोई क्रेडिट कार्ड आवश्यक नहीं.
अपना $5 क्रेडिट क्लेम करें →FAQ
क्या केवल concurrency limit रेट लिमिट्स का सम्मान करने के लिए पर्याप्त है?
अनुरोध दर लागू करने के लिए केवल एक concurrency limit पर्याप्त नहीं है। नए अनुरोधों की संख्या इस पर निर्भर करती है कि सक्रिय अनुरोध कितनी जल्दी समाप्त होते हैं। सक्रिय ऑपरेशनों की अधिकतम सीमा के साथ एक shared start-rate बजट का उपयोग करें, और हर उस process को शामिल करें जो वही account allowance खर्च करता है।
क्या HTTP 429 हमेशा पूरी limit policy दिखाता है?
HTTP 429 स्वयं पूरी counting policy प्रकट नहीं करता। प्रदाता तय करता है कि कौन‑सी caller identity, endpoint और time window लागू होती है। प्रलेखित error विवरण और account policy पढ़ें, और जब अनुरोध स्वीकार न किए गए हों तो संबंधित collection को अधूरा चिह्नित रखें।
क्या हर collector को सबसे बड़ा page size उपयोग करना चाहिए?
सबसे बड़ा समर्थित page size हमेशा सबसे अच्छा विकल्प नहीं होता। बड़े responses के लिए अधिक memory और processing time की आवश्यकता हो सकती है, और कुछ प्रदाता अनुरोधों की संख्या के बजाय किए गए work के आधार पर शुल्क लेते हैं। किसी प्रतिनिधि task की response cost और storage सीमाओं की जाँच करने के बाद एक समर्थित size चुनें।
क्या कोई proxy या managed service permission limits हटा सकता है?
कोई proxy या managed service स्रोत की सीमाओं से आगे जाने की अनुमति नहीं देता। अनुरोधों को लागू access terms और अधिकृत scope के भीतर रखें। Network routing, service billing और किसी dataset को एकत्र करने की permission अलग‑अलग जिम्मेदारियाँ बनी रहती हैं।
एक अधूरे, rate‑limited रिपोर्ट में क्या होना चाहिए?
एक अधूरी रिपोर्ट को अपने collected scope, missing scope, रुकने का कारण और आखिरी committed checkpoint की पहचान करनी चाहिए। observation समय और sanitized error साक्ष्य शामिल करें ताकि उपभोक्ता coverage और freshness का आकलन कर सकें। कोई collection तभी complete मानी जानी चाहिए जब उसकी अपनी प्रलेखित completion conditions पूरी हों।