एपीआई प्रदर्शन: रेट लिमिटिंग, पेजिनेशन और एसिंक प्रोसेसिंग

आपका एपीआई पीक लोड के तहत अपने सबसे धीमे समापन बिंदु जितना ही तेज़ है। एक एकल गैर-अनुकूलित समापन बिंदु जो 5 सेकंड के लिए डेटाबेस कनेक्शन रखता है, आपके कनेक्शन पूल को ख़त्म कर सकता है और आपके पूरे प्लेटफ़ॉर्म पर विफलताओं को कैस्केड कर सकता है। एपीआई प्रदर्शन इंजीनियरिंग तीन स्तंभों पर केंद्रित है: आपके एपीआई को ओवरलोड (दर सीमित करना) से बचाना, बड़े डेटासेट को कुशलतापूर्वक संभालना (पेगिनेशन), और महंगे संचालन को अनुरोध चक्र (एसिंक प्रोसेसिंग) से बाहर ले जाना।

मुख्य बातें

• टोकन बकेट और स्लाइडिंग विंडो दो दर सीमित एल्गोरिदम हैं जो 95% उपयोग के मामलों को कवर करते हैं - इस आधार पर चुनें कि आप बर्स्ट टॉलरेंस चाहते हैं या सख्त प्रवर्तन
• कर्सर-आधारित पेजिनेशन बड़े डेटासेट के लिए ऑफसेट पेजिनेशन से बेहतर प्रदर्शन करता है क्योंकि यह छोड़ी गई पंक्तियों की गिनती से बचता है
• नौकरी कतारों के साथ एसिंक प्रसंस्करण ईमेल भेजने, पीडीएफ पीढ़ी और वेबहुक डिलीवरी को अनुरोध पथ से बाहर ले जाकर P95 प्रतिक्रिया समय को कम करता है
• ब्रॉटली के साथ प्रतिक्रिया संपीड़न पेलोड आकार को 70-85% तक कम कर देता है, जो सीधे तेज़ क्लाइंट-साइड रेंडरिंग में अनुवादित होता है

---

दर सीमित एल्गोरिदम

दर सीमित करना आपके एपीआई को दुरुपयोग से बचाता है, उचित संसाधन आवंटन सुनिश्चित करता है, और ट्रैफ़िक स्पाइक्स के दौरान कैस्केड विफलताओं को रोकता है। आपके द्वारा चुना गया एल्गोरिदम यह निर्धारित करता है कि विस्फोटों को कैसे नियंत्रित किया जाता है और उपभोक्ताओं के लिए सीमित व्यवहार कितना अनुमानित है।

टोकन बकेट

अधिकांश एपीआई के लिए टोकन बकेट एल्गोरिदम सबसे व्यावहारिक विकल्प है। एक बाल्टी अधिकतम क्षमता तक टोकन रखती है। टोकन एक निश्चित दर (रीफिल दर) पर जोड़े जाते हैं। प्रत्येक अनुरोध में एक टोकन की खपत होती है। यदि बकेट खाली है, तो अनुरोध अस्वीकार कर दिया जाता है या कतारबद्ध कर दिया जाता है।

टोकन बकेट का मुख्य लाभ विस्फोट सहनशीलता है। यदि किसी ग्राहक ने कुछ समय से अनुरोध नहीं किया है, तो उनकी बाल्टी भर गई है और वे बाल्टी की क्षमता तक अनुरोधों की झड़ी लगा सकते हैं। यह प्राकृतिक उपयोग पैटर्न से मेल खाता है - एक क्लाइंट जो डैशबोर्ड लोड करता है वह तेजी से उत्तराधिकार में 20 अनुरोध कर सकता है, फिर 30 सेकंड तक कुछ भी नहीं।

ईकॉमर्स एपीआई के लिए कॉन्फ़िगरेशन उदाहरण:

• बाल्टी का आकार: 100 टोकन
• रीफिल दर: 10 टोकन प्रति सेकंड
• यह लंबे समय तक प्रति सेकंड 10 अनुरोधों को बनाए रखते हुए 100 अनुरोधों तक के विस्फोट की अनुमति देता है

स्लाइडिंग विंडो काउंटर

स्लाइडिंग विंडो काउंटर निश्चित विंडो की मेमोरी दक्षता के साथ स्लाइडिंग विंडो लॉग की सटीकता को जोड़ता है। यह वर्तमान और पिछली विंडो के लिए काउंटर बनाए रखता है, फिर अनुरोध वर्तमान विंडो में कितनी दूर तक आता है, उसके आधार पर एक भारित गणना की गणना करता है।

45 सेकंड में मूल्यांकन की गई 60-सेकंड की विंडो के लिए, प्रभावी गिनती है: (पिछली विंडो गिनती * 0.25) + (वर्तमान विंडो गिनती)। यह व्यक्तिगत अनुरोध टाइमस्टैम्प को संग्रहीत किए बिना निश्चित विंडो की सीमा फटने की समस्या को समाप्त करता है।

रेडिस के साथ कार्यान्वयन

रेडिस वितरित दर सीमित करने के लिए मानक बैकिंग स्टोर है क्योंकि यह टीटीएल के साथ परमाणु वृद्धि संचालन प्रदान करता है। स्थिर विंडो के लिए EXPIRE के साथ INCR का उपयोग करें, या स्लाइडिंग विंडो के लिए ZADD और ZRANGEBYSCORE के साथ क्रमबद्ध सेट का उपयोग करें। टोकन बकेट के लिए, रेडिस लुआ स्क्रिप्ट परमाणु चेक-एंड-डिक्रीमेंट ऑपरेशन प्रदान करती है।

दर सीमित करने वाले हेडर एपीआई उपभोक्ताओं को सीमाएं बताते हैं:

• X-RateLimit-Limit -- विंडो में अधिकतम अनुमत अनुरोध
• X-RateLimit-Remaining -- अनुरोध वर्तमान विंडो में शेष हैं
• X-RateLimit-Reset -- विंडो रीसेट होने पर यूनिक्स टाइमस्टैम्प
• Retry-After -- क्लाइंट द्वारा पुनः प्रयास करने तक सेकंड (429 प्रतिक्रियाओं पर)

---

पेजिनेशन रणनीतियाँ

प्रत्येक सूची समापन बिंदु को पृष्ठांकित किया जाना चाहिए। असीमित परिणाम लौटाने से बैंडविड्थ बर्बाद होती है, डेटाबेस पर दबाव पड़ता है, और डेटा बढ़ने पर टाइमआउट त्रुटियों का जोखिम होता है।

ऑफसेट पेजिनेशन

ऑफसेट पेजिनेशन LIMIT और OFFSET SQL क्लॉज का उपयोग करता है। क्लाइंट ?page=3&limit=20 का अनुरोध करता है, और सर्वर OFFSET 40 LIMIT 20 में अनुवाद करता है।

फायदे:

• लागू करने और समझने में सरल
• ग्राहक सीधे किसी भी पेज पर जा सकते हैं
• कुल गणना "Y का पृष्ठ X" UI सक्षम करती है

नुकसान:

• उच्च ऑफसेट के साथ प्रदर्शन में गिरावट आती है - OFFSET 1000000 परिणाम लौटाने से पहले अभी भी 1,000,000 पंक्तियों को स्कैन करता है
• जब पृष्ठों के बीच डेटा बदलता है तो असंगत परिणाम (नया डेटा डालने या हटाए जाने पर पंक्तियाँ बदल जाती हैं)
• बड़ी तालिकाओं पर कुल गणना क्वेरी (COUNT(*)) महंगी हो सकती है

कर्सर-आधारित पेजिनेशन

कर्सर-आधारित पेजिनेशन परिणाम सेट में स्थिति को चिह्नित करने के लिए एक अपारदर्शी कर्सर (आमतौर पर एक एन्कोडेड प्राथमिक कुंजी या टाइमस्टैम्प) का उपयोग करता है। क्लाइंट ?cursor=abc123&limit=20 का अनुरोध करता है, और सर्वर कर्सर को WHERE क्लॉज के रूप में उपयोग करता है: WHERE id > decoded(abc123) LIMIT 20।

फायदे:

• डेटासेट में स्थिति की परवाह किए बिना लगातार प्रदर्शन - कोई ऑफसेट स्कैनिंग नहीं
• पेजों के बीच डेटा बदलने पर भी स्थिर परिणाम
• अनंत स्क्रॉल और वास्तविक समय फ़ीड के लिए प्राकृतिक फिट

नुकसान:

• मनमाने पेजों पर नहीं जा सकते (नहीं "पेज 50 पर जाएं")
• कार्यान्वयन के लिए अधिक जटिल, विशेष रूप से मल्टी-कॉलम सॉर्ट ऑर्डर के साथ
• यदि आवश्यक हो तो कुल संख्या अलग से प्रदान की जानी चाहिए

किस पेजिनेशन का उपयोग करें

पृष्ठांकन प्रतिक्रिया प्रारूप

एक अच्छी तरह से डिज़ाइन की गई पृष्ठांकन प्रतिक्रिया में मेटाडेटा शामिल होता है जिसे ग्राहकों को नेविगेट करने की आवश्यकता होती है:

{
  "data": [],
  "pagination": {
    "total": 15432,
    "limit": 20,
    "hasMore": true,
    "nextCursor": "eyJpZCI6MTAwfQ=="
  }
}

---

जॉब कतारों के साथ एसिंक प्रोसेसिंग

सिंक्रोनस एपीआई एंडपॉइंट को 200ms के भीतर प्रतिक्रियाएँ लौटानी चाहिए। कोई भी ऑपरेशन जिसमें अधिक समय लगता है - ईमेल भेजना, पीडीएफ तैयार करना, छवियों को संसाधित करना, बाहरी एपीआई को कॉल करना, रिपोर्ट चलाना - को पृष्ठभूमि कार्य कतार में ले जाया जाना चाहिए।

नौकरी कतार पैटर्न

1. एपीआई एंडपॉइंट अनुरोध को मान्य करता है और एक जॉब रिकॉर्ड बनाता है
2. कार्य को कतार में रखा गया है (रेडिस, रैबिटएमक्यू, एसक्यूएस)
3. एपीआई 202 स्वीकृत प्रतिक्रिया और जॉब आईडी के साथ तुरंत लौटता है
4. एक कार्यकर्ता प्रक्रिया कार्य चुनती है और उसे अतुल्यकालिक रूप से निष्पादित करती है
5. ग्राहक नौकरी की स्थिति के लिए मतदान करता है या पूरा होने पर वेबहुक कॉलबैक प्राप्त करता है

सामान्य एसिंक उपयोग के मामले

ईमेल भेजना--एसएमटीपी परिचालन में प्रदाता के आधार पर 500ms-3s का समय लगता है। ईमेल को कतारबद्ध करने से एपीआई प्रतिक्रिया समय कम हो जाता है और उपयोगकर्ता को अवरुद्ध किए बिना क्षणिक विफलताओं के लिए तर्क को पुनः प्रयास करने की अनुमति मिलती है।

पीडीएफ पीढ़ी -- चालान, रिपोर्ट, या निर्यात फ़ाइलें उत्पन्न करना सीपीयू-गहन और मेमोरी-भारी है। इन्हें समर्पित कार्यकर्ताओं में चलाने से एपीआई अनुरोध प्रबंधन के साथ संसाधन विवाद को रोका जा सकता है।

वेबहुक डिलीवरी -- आउटगोइंग वेबहुक तीसरे पक्ष के सर्वर की उपलब्धता पर निर्भर करता है। आपके सिस्टम को अवरुद्ध किए बिना अस्थायी विफलताओं को संभालने के लिए घातीय बैकऑफ़ पुनः प्रयास (1s, 2s, 4s, 8s, 5 मिनट तक) के साथ कतारबद्ध वेबहुक डिलीवरी।

डेटा आयात और निर्यात -- 100,000 पंक्तियों के साथ सीएसवी अपलोड का प्रसंस्करण अनुरोध चक्र में कभी नहीं होना चाहिए। अपलोड स्वीकार करें, जॉब आईडी लौटाएं और पंक्तियों को बैचों में संसाधित करें।

कतार चयन

---

प्रतिक्रिया अनुकूलन

एप्लिकेशन तर्क से परे, प्रतिक्रिया को आकार और वितरण गति के लिए अनुकूलित किया जा सकता है।

संपीड़न

नेटवर्क पर पेलोड आकार को कम करने के लिए प्रतिक्रिया संपीड़न सक्षम करें। आधुनिक संपीड़न एल्गोरिदम टेक्स्ट-आधारित पेलोड (JSON, HTML, CSS, JavaScript) को काफी कम कर देते हैं।

स्थिर संपत्तियों के लिए ब्रॉटली का उपयोग करें (निर्माण के समय पूर्व-संपीड़ित) और गतिशील प्रतिक्रियाओं के लिए फ़ॉलबैक के रूप में gzip का उपयोग करें। NestJS में, कंप्रेशन मिडलवेयर इसे स्वचालित रूप से संभालता है, लेकिन उत्पादन में, Nginx को आपके एप्लिकेशन सर्वर से सीपीयू को ऑफलोड करने के लिए कंप्रेशन को संभालने देता है।

फ़ील्ड चयन

एपीआई उपभोक्ताओं को केवल उन्हीं फ़ील्ड का अनुरोध करने की अनुमति दें जिनकी उन्हें आवश्यकता है। GraphQL यह स्वाभाविक रूप से करता है, लेकिन REST API ?fields=id,name,price क्वेरी पैरामीटर के साथ फ़ील्ड चयन का समर्थन कर सकता है। यह पेलोड आकार को कम करता है और केवल आवश्यक कॉलम का चयन करके डेटाबेस क्वेरी को अनुकूलित कर सकता है।

रिस्पांस कैशिंग हेडर

एपीआई प्रतिक्रियाओं पर उचित कैश-कंट्रोल हेडर सेट करें। सार्वजनिक सूची समापन बिंदु (उत्पाद, श्रेणियां) 5 मिनट के लिए कैश करने के लिए Cache-Control: public, max-age=300 का उपयोग कर सकते हैं। पुनर्वैधीकरण के साथ ब्राउज़र कैशिंग की अनुमति देते समय सीडीएन कैशिंग को रोकने के लिए प्रमाणित समापन बिंदुओं को Cache-Control: private, no-cache का उपयोग करना चाहिए।

कैशिंग रणनीतियों पर अधिक जानकारी के लिए, रेडिस, सीडीएन, और HTTP कैशिंग पर हमारी विस्तृत मार्गदर्शिका देखें।

---

कनेक्शन प्रबंधन

डेटाबेस और HTTP कनेक्शन सीमित संसाधन हैं जिन्हें लोड के तहत सावधानीपूर्वक प्रबंधित किया जाना चाहिए।

डेटाबेस कनेक्शन पूलिंग

एक कनेक्शन पूल पुन: प्रयोज्य डेटाबेस कनेक्शन का एक सेट बनाए रखता है। पूलिंग के बिना, प्रत्येक एपीआई अनुरोध एक नया डेटाबेस कनेक्शन (50-100ms ओवरहेड) खोलता है और प्रतिक्रिया के बाद इसे बंद कर देता है। पूलिंग के साथ, अनुरोध पूल से कनेक्शन उधार लेते हैं और पूरा होने पर उन्हें वापस कर देते हैं।

पूल आकार निर्धारण सूत्र: कनेक्शन = (कोर_काउंट * 2) + इफेक्टिव_स्पिंडल_काउंट। एसएसडी स्टोरेज वाले 4-कोर सर्वर के लिए, प्रति एप्लिकेशन इंस्टेंस 10-20 कनेक्शन एक अच्छा शुरुआती बिंदु है। पूल उपयोग की निगरानी करें - यदि यह नियमित रूप से 80% से अधिक है, तो या तो पूल आकार बढ़ाएं या क्वेरी अवधि अनुकूलित करें।

HTTP कीप-अलाइव

अपस्ट्रीम सेवाओं (डेटाबेस, रेडिस, बाहरी एपीआई) से कनेक्शन के लिए HTTP को सक्रिय रखें। यह प्रति अनुरोध नए कनेक्शन स्थापित करने के बजाय टीसीपी कनेक्शन का पुन: उपयोग करता है, जिससे टीसीपी हैंडशेक और टीएलएस बातचीत ओवरहेड (प्रति नए कनेक्शन 50-200 एमएस) समाप्त हो जाता है।

---

अक्सर पूछे जाने वाले प्रश्न

सार्वजनिक एपीआई के लिए मुझे कौन सी दर सीमा निर्धारित करनी चाहिए?

रूढ़िवादी सीमाओं से शुरू करें और वैध उपयोग पैटर्न के आधार पर समायोजन करें। एक सामान्य प्रारंभिक बिंदु प्रमाणित उपयोगकर्ताओं के लिए प्रति मिनट 100 अनुरोध और अनाम उपयोगकर्ताओं के लिए प्रति मिनट 20 अनुरोध है। 429 प्रतिक्रिया दरों की निगरानी करें - यदि वैध उपयोगकर्ता बार-बार सीमा पार करते हैं, तो उन्हें बढ़ाएँ। प्रीमियम एपीआई स्तरों के लिए उच्च सीमाएँ प्रदान करें।

जब पेजों के बीच डेटा बदलता है तो मैं पेजिनेशन कैसे संभालूं?

कर्सर-आधारित पेजिनेशन इसे स्वाभाविक रूप से संभालता है क्योंकि यह सॉर्ट किए गए डेटा में एक विशिष्ट स्थिति पर आधारित होता है। ऑफसेट पेजिनेशन के साथ, परिणामी दस्तावेज़ पृष्ठों के बीच स्थानांतरित हो सकते हैं। महत्वपूर्ण उपयोग के मामलों (वित्तीय रिपोर्ट, डेटा निर्यात) के लिए, पेजिनेशन की शुरुआत में डेटा को स्नैपशॉट करें और स्नैपशॉट पर पेजिनेट करें।

क्या मुझे प्रदर्शन के लिए REST या GraphQL का उपयोग करना चाहिए?

फ़ील्ड चयन और उचित कैशिंग के साथ REST सरल, अच्छी तरह से परिभाषित समापन बिंदुओं के लिए तेज़ है। ग्राफक्यूएल जटिल डेटा आवश्यकताओं के लिए ओवर-फ़ेचिंग और अंडर-फ़ेचिंग को समाप्त करता है लेकिन क्वेरी पार्सिंग ओवरहेड जोड़ता है और HTTP कैशिंग को कठिन बनाता है। कैशिंग आवश्यकताओं वाले सार्वजनिक एपीआई के लिए REST का उपयोग करें और जटिल फ्रंटएंड डेटा आवश्यकताओं को पूरा करने वाले आंतरिक एपीआई के लिए ग्राफक्यूएल का उपयोग करें।

मैं उत्पादन में एपीआई प्रदर्शन की निगरानी कैसे करूं?

प्रति समापन बिंदु पर P50, P95 और P99 प्रतिक्रिया समय ट्रैक करें। अपने SLO (आमतौर पर 200-500ms) का उल्लंघन करने वाले P95 पर अलर्ट सेट करें। डेटाबेस, कैश, बाहरी सेवाओं और एप्लिकेशन लॉजिक में बिताए गए समय को विभाजित करने के लिए वितरित ट्रेसिंग का उपयोग करें। विस्तृत सेटअप के लिए निगरानी और अवलोकन पर हमारी मार्गदर्शिका देखें।

---

आगे क्या है

लापता पेजिनेशन, दर सीमा के बिना असुरक्षित सार्वजनिक एंडपॉइंट और एसिंक्स होने वाले सिंक्रोनस ऑपरेशंस के लिए अपने एपीआई एंडपॉइंट्स का ऑडिट करके प्रारंभ करें। ये तीन परिवर्तन आमतौर पर P95 प्रतिक्रिया समय को 50-70% तक कम कर देते हैं और सबसे आम उत्पादन घटनाओं को रोकते हैं।

संपूर्ण प्रदर्शन इंजीनियरिंग परिप्रेक्ष्य के लिए, आपके व्यवसाय प्लेटफ़ॉर्म को स्केल करना पर हमारी स्तंभ मार्गदर्शिका देखें। आपके एपीआई को शक्ति प्रदान करने वाली डेटाबेस परत के लिए, हमारी क्वेरी अनुकूलन मार्गदर्शिका पढ़ें।

ECOSIRE Odoo ERP और कस्टम आर्किटेक्चर पर व्यावसायिक प्लेटफार्मों के लिए उच्च-प्रदर्शन एपीआई बनाता है। एपीआई प्रदर्शन समीक्षा के लिए हमसे संपर्क करें।

---

ECOSIRE द्वारा प्रकाशित - Odoo ERP, Shopify eCommerce, और OpenClaw AI में AI-संचालित समाधानों के साथ व्यवसायों को बढ़ाने में मदद करना।