एक ही उपयोग-पथ की तुलना
दशमलव किलोबाइट का काल्पनिक उदाहरण: पहले 100 कॉल और हर उत्तर 100 kB; विकल्प में 20 कॉल और हर उत्तर 50 kB। कुल मात्रा 10000 से 1000 kB, यानी 90 % कम होती है। इससे विलंब में समान कमी साबित नहीं होती। गणना में केवल उत्तर की बॉडी है, अनुरोध और हेडर नहीं।
| काल्पनिक माप | पहले | विकल्प |
|---|---|---|
| कॉल | 100 | 20 |
| प्रति उत्तर मात्रा | 100 kB | 50 kB |
| कुल मात्रा | 10000 kB | 1000 kB |
| पूरे पथ का समय | मापना होगा | मापना होगा |
समानांतरता से पहले काम घटाएँ
- ज़रूरी फ़ील्ड ही माँगें और दर्ज पृष्ठांकन नियम अपनाएँ। बैच में सीमा और आंशिक परिणामों का प्रबंधन चाहिए; बड़ा पृष्ठ हमेशा तेज़ नहीं होता।
- संदर्भ और ताज़गी की शर्तें पूरी हों तो कनेक्शन तथा उत्तर दोबारा उपयोग करें। समानांतर काम सीमित करें और सर्वर का काम व कतार भी मापें।
- कुल समय-सीमा और अधिकतम प्रयास तय करें। अस्थायी विफलता के प्रयासों में यादृच्छिक प्रतीक्षा जोड़ें और देखें कि दूसरी परतें पहले से प्रयास तो नहीं कर रहीं।
पूरी हो चुकी कार्रवाई न दोहराएँ
क्लाइंट का टाइमआउट सर्वर पर रद्द होने का प्रमाण नहीं है। निर्माण या भुगतान दोहराने से पहले स्थिति और प्रदाता की इडेम्पोटेंसी व्यवस्था जाँचें। प्रतिनिधि भार पर समय, त्रुटि और डेटा की शुद्धता की तुलना करें।
प्राथमिक स्रोत
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
एक API रिस्पॉन्स के पीछे के काम की जाँच करें।
एक सिंगल GraphQL क्वेरी कई डाउनस्ट्रीम कॉल ट्रिगर कर सकती है। क्लाइंट-विज़िबल लेटेंसी रिज़ॉल्वर, लिस्ट और ट्रैवर्स किए गए रिलेशनशिप की कॉस्ट छिपा सकती है।
- क्लाइंट से डाउनस्ट्रीम सर्विसेज़ तक एक ऑपरेशन को ट्रेस करें।
- फील्ड कॉस्ट और असल में यूज़फुल वॉल्यूम की तुलना करें।
- कैश करने से पहले बाउंड लिस्ट और बार-बार की गई क्वेरी।
प्राथमिक स्रोत: OWASP — GraphQL Cheat Sheet. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
Retry-After: प्रतीक्षा, बजट और पुनःप्रयास
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS