मुख्य सामग्री पर जाएं

रेट लिमिट

MarkdownChatGPTClaude

रेट लिमिट यह परिभाषित करता है कि कोई एप्लिकेशन किसी निर्दिष्ट समय अवधि के भीतर API को अधिकतम कितनी रिक्वेस्ट भेज सकता है। सेवाओं के समग्र स्वास्थ्य और विश्वसनीयता को बनाए रखने के लिए यह तंत्र महत्वपूर्ण है।

हम रेट लिमिटिंग का इस्तेमाल क्यों करते हैं​

API stability and performance
  • किसी एक क्लाइंट को अत्यधिक रिक्वेस्ट से सर्वर पर हावी होने से रोकता है।
  • सभी क्लाइंट के लिए सुसंगत और अनुमानित रिस्पॉन्स समय सुनिश्चित करता है।
  • बैकएंड सेवाओं को अप्रत्याशित ट्रैफ़िक स्पाइक से बचाता है।
  • इंफ्रास्ट्रक्चर पर एक स्थिर और नियंत्रित लोड पैटर्न बनाए रखता है।
Security
  • ब्रूट फ़ोर्स जैसे हमले के प्रयासों के विरुद्ध सुरक्षा को मज़बूत करता है।
  • डिस्ट्रिब्यूटेड डिनायल-ऑफ़-सर्विस (DDoS) के जोखिम को कम करता है।
  • खराब ढंग से लागू किए गए इंटीग्रेशन से होने वाले प्रभाव को कम करता है।
  • कॉम्प्रोमाइज़ हुए API क्रेडेंशियल से होने वाले संभावित नुकसान को सीमित करता है।
Resource allocation
  • सभी क्लाइंट के लिए API संसाधनों तक संतुलित पहुँच सुनिश्चित करता है।
  • कुछ के दुरुपयोग को अन्य यूज़र के अनुभव को खराब करने से रोकता है।
  • बिज़नेस मानदंड और ज़रूरतों के अनुसार ट्रैफ़िक को प्राथमिकता देने देता है।
  • API के अधिक कुशल और टिकाऊ उपभोग के तरीकों को प्रोत्साहित करता है।

रेट लिमिटिंग कैसे काम करती है​

हर API कॉल अनुमत requests-per-second लिमिट में गिनी जाती है। डिफ़ॉल्ट वैल्यू प्रति टेनेंट 10 RPS है। लिमिट पार होने पर, API HTTP 429 Too Many Requests लौटाता है।

Unico टीम से पुष्टि करें

सटीक लिमिट प्रति टेनेंट कॉन्फ़िगर की जाती हैं। हाई-थ्रूपुट इंटीग्रेशन के लिए साइज़िंग करने से पहले, अपने अकाउंट पर लागू लिमिट की पुष्टि करने के लिए Unico टीम से संपर्क करें।

429 त्रुटियों को हैंडल करना​

Request a rate limit increase

अगर आपके ऑपरेशन में रिक्वेस्ट वॉल्यूम में वृद्धि होगी (अस्थायी या स्थायी रूप से), तो अपने एनवायरनमेंट के लिए रेट लिमिट बढ़ाने के लिए Unico टीम को सूचित करें। यह अनुरोध वॉल्यूम में वृद्धि होने से पहले किया जाना चाहिए ताकि आपका एप्लिकेशन निष्क्रिय न हो जाए।

Review application behavior
  • अकुशल API उपयोग पैटर्न की पहचान करने के लिए अपने कोड का ऑडिट करें।
  • अनजाने लूप या रिडंडेंट API कॉल की जाँच करें।
  • रिक्वेस्ट को बड़े बर्स्ट में भेजने के बजाय समय के साथ अधिक समान रूप से वितरित करें।
Implement caching
  • बार-बार एक्सेस किए जाने वाले डेटा को कैश करें जो शायद ही कभी बदलता है।
  • OAuth2 एक्सेस टोकन का इस्तेमाल इसके पूरे 1-घंटे के TTL के लिए करें — हर रिक्वेस्ट पर POST /oauth2/token कॉल न करें।
  • उपयुक्त कैश इनवैलिडेशन रणनीतियाँ लागू करें।
Use webhooks instead of polling

GET /client/v1/process/\{id\} को पोल करने के बजाय PROCESS_STATE_FINISHED के लिए Webhooks and Events सब्सक्राइब करें। भारी ट्रैफ़िक पर एक पोलिंग लूप GET-process बजट को आसानी से खत्म कर सकता है।

लिमिट पर पहुँचने पर क्या होता है​

प्लेटफ़ॉर्म यह लौटाता है:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
HeaderMeaning
Retry-Afterरीट्राई करने से पहले प्रतीक्षा करने के लिए सेकंड की संख्या। इसका पालन करें।

अगर Retry-After मौजूद नहीं है, तो 60s पर सीमित एक्सपोनेंशियल बैकऑफ़ (1s, 2s, 4s, 8s, …) पर वापस जाएँ।

कंकरेंसी संबंधी विचार​

रेट लिमिट प्रति मिनट रिक्वेस्ट को सीमित करते हैं, लेकिन प्लेटफ़ॉर्म में इंफ्रास्ट्रक्चर स्तर पर कंकरेंसी कैप भी हैं। भले ही आपके पास 100 रिक्वेस्ट/मिनट का बजट हो, सभी 100 को एक ही सेकंड में भेजना पूरे मिनट में फैलाने की तुलना में अस्वीकृत होने की अधिक संभावना रखता है।

हाई-थ्रूपुट इंटीग्रेशन के लिए, बर्स्ट के बजाय एक स्थिर RPS को लक्ष्य बनाएँ।

Trully के पास Webhook V2 के लिए अपना डिलीवरी कोटा है। वेबहुक सर्वर से 1 मिनट के भीतर रिस्पॉन्स देने की अपेक्षा की जाती है; धीमे रिस्पॉन्स को छोड़ दिया जाता है (यूज़र की प्रोसेस प्रभावित नहीं होती)। सुसंगत प्रोसेसिंग के लिए, वेबहुक को तुरंत स्वीकार करें और इसे असिंक्रोनस रूप से प्रोसेस करें।

आगे क्या​

अंतिम अपडेट को