विलंबता, थ्रूपुट और लागत के बीच समझौते

हर सर्विंग विकल्प में तीन चीज़ों का संतुलन बनाना पड़ता है: विलंबता, थ्रूपुट और लागत। किसी एक पर ज़ोर देने से आमतौर पर बाकी दो प्रभावित होते हैं।

विलंबता किसी एक पूर्वानुमान के वापस आने में लगने वाला समय है। कम विलंबता तेज़ अनुभव देती है; अधिक विलंबता उपयोगकर्ताओं और आगे की प्रणालियों को प्रतीक्षा करवाती है।

थ्रूपुट यह बताता है कि आप प्रति सेकंड कितने पूर्वानुमान दे सकते हैं। हर कॉल तेज़ होने पर भी भारी लोड में सेवा को उच्च थ्रूपुट की आवश्यकता हो सकती है।

अनुरोधों को एक बैच में समूहित करने से थ्रूपुट बढ़ता है, लेकिन प्रतीक्षा का समय भी बढ़ता है, इसलिए हर कॉल की विलंबता अधिक हो जाती है। ये दोनों लक्ष्य अक्सर एक-दूसरे के विपरीत होते हैं।

अधिक मशीनें विलंबता घटाती और थ्रूपुट बढ़ाती हैं, लेकिन बिल बढ़ जाता है। सेवा का आकार तय करते समय लागत को नज़रअंदाज़ नहीं किया जा सकता।

SLA आपका लक्ष्य तय करता है, जैसे 100 मिलीसेकंड से कम समय में 95% अनुरोध पूरे करना। यह अस्पष्ट लक्ष्यों को ऐसी संख्या में बदल देता है जिसके आधार पर आप डिज़ाइन और माप कर सकते हैं।

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

ट्रैफ़िक बाँटने के लिए अधिक प्रतिकृतियाँ जोड़ें। क्षैतिज विस्तार थ्रूपुट बढ़ाता और विलंबता की रक्षा करता है, लेकिन कंप्यूटिंग खर्च अधिक हो जाता है।

औसत आँकड़े समस्या छिपा देते हैं। धीमा p99 अनुरोध ही वह होता है जिसकी उपयोगकर्ता शिकायत करते हैं, इसलिए केवल सामान्य स्थिति नहीं, अंतिम हिस्से के लिए भी अनुकूलन करें।

बड़े मॉडल पर GPU थ्रूपुट को बहुत बढ़ा सकता है, लेकिन कम ट्रैफ़िक में निष्क्रिय पड़ा रह सकता है। अनावश्यक खर्च से बचने के लिए हार्डवेयर को अपने वास्तविक लोड के अनुसार चुनें।

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

विलंबता, थ्रूपुट और लागत एक ऐसे त्रिकोण का निर्माण करते हैं जिसे आप एक साथ अधिकतम नहीं कर सकते। SLA तय करें, फिर आवश्यक संतुलन पाने के लिए बैचिंग और विस्तार का उपयोग करें।