क्या API Gateway में धीमे Requests अन्य Requests को प्रभावित करेंगे?

API गेटवे के क्षेत्र में अक्सर चर्चा की जाने वाली एक चिंता यह है कि बड़ी संख्या में समवर्ती अनुरोधों को कुशलतापूर्वक संभालने की क्षमता हो। विशेष रूप से, यह सवाल उठता है: क्या धीमे अनुरोध API गेटवे में अन्य सामान्य अनुरोधों के प्रतिक्रिया समय को महत्वपूर्ण रूप से बढ़ा देंगे?

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

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

मान लीजिए कि हजारों समवर्ती अनुरोध हैं, तो मल्टीथ्रेडिंग या मल्टीप्रोसेसिंग आर्किटेक्चर (जैसे Java या Python में) का उपयोग करने के लिए अनुरोध संदर्भों को प्रबंधित करने के लिए हजारों थ्रेड या प्रक्रियाओं का आवंटन करना आवश्यक होता है। कंप्यूटर प्रोग्रामिंग से परिचित लोग जानते हैं कि, भले ही अधिकांश थ्रेड निष्क्रिय हों, ऑपरेटिंग सिस्टम को हजारों थ्रेड या प्रक्रियाओं को बनाए रखने के लिए हार्डवेयर संसाधनों की खपत होती है। हालांकि, कोरोटीन (जैसे APISIX और Golang में) का उपयोग करने पर, समवर्ती अनुरोधों में वृद्धि होने पर भी अतिरिक्त थ्रेड या प्रक्रियाओं की आवश्यकता नहीं होती है।

कोरोटीन, थ्रेड और प्रक्रियाएं सभी मल्टीटास्किंग के दृष्टिकोण को प्रस्तुत करते हैं, लेकिन इनमें मुख्य अंतर होते हैं:

1. शेड्यूलिंग मैकेनिज्म: थ्रेड/प्रक्रिया शेड्यूलिंग प्रीमेप्टिव होती है, और ऑपरेटिंग सिस्टम (OS) द्वारा प्रबंधित की जाती है, जिसका अर्थ है कि OS यह तय करता है कि कब इंटरप्ट करना है और दूसरे थ्रेड या प्रक्रिया पर स्विच करना है। इसके विपरीत, कोरोटीन शेड्यूलिंग सहकारी होती है, जो स्पष्ट रूप से प्रोग्रामर या भाषा लाइब्रेरी द्वारा संचालित होती है। कोरोटीन को अन्य कोरोटीन पर स्विच करने के लिए स्पष्ट रूप से नियंत्रण छोड़ना आवश्यक होता है।

2. ओवरहेड: थ्रेड/प्रक्रियाएं, ऑपरेटिंग सिस्टम स्तर पर होने के कारण, निर्माण, स्विचिंग और समाप्ति के लिए अधिक संसाधनों की आवश्यकता होती है। इसके विपरीत, कोरोटीन यूजर स्पेस में काम करते हैं, जिसके परिणामस्वरूप निर्माण, स्विचिंग और समाप्ति के लिए अपेक्षाकृत कम ओवरहेड होता है।

3. डेटा शेयरिंग और सिंक्रोनाइज़ेशन: इंटर-थ्रेड/प्रक्रिया डेटा शेयरिंग के लिए डेटा रेस कंडीशन को रोकने के लिए म्यूटेक्स लॉक, रीड-राइट लॉक, सेमाफोर आदि जैसे जटिल सिंक्रोनाइज़ेशन ऑपरेशन की आवश्यकता होती है। कोरोटीन, एक ही थ्रेड के भीतर होने के कारण, सीधे ग्लोबल वेरिएबल्स को शेयर कर सकते हैं, जटिल सिंक्रोनाइज़ेशन की आवश्यकता के बिना।

APISIX की दुनिया में, धीमे अनुरोध केवल अपस्ट्रीम प्रतिक्रियाओं की प्रतीक्षा करने तक सीमित होते हैं, यह प्रक्रिया नेटवर्क इवेंट्स को सुनने तक सीमित होती है, जिसमें अतिरिक्त सिस्टम संसाधन ओवरहेड नहीं होता है। अंत में, APISIX कुछ अनुरोधों के लंबे प्रतिक्रिया समय के कारण अन्य सामान्य अनुरोधों के प्रतिक्रिया समय को समझौता नहीं करता है।