मैं k6 के साथ नया हूं और अगर मैं कुछ भोला पूछ रहा हूं तो मुझे खेद है। मैं यह समझने की कोशिश कर रहा हूं कि यह टूल हुड के तहत नेटवर्क कॉल को कैसे प्रबंधित करता है। क्या यह उन्हें अधिकतम दर से क्रियान्वित कर रहा है? क्या यह सिस्टम अंडर टेस्ट के प्रतिक्रिया समय के आधार पर उन्हें कतारबद्ध कर रहा है?

मुझे इसे प्राप्त करने की आवश्यकता है क्योंकि मैं k6 run और k6 cloud दोनों का उपयोग करके बहुत सारे परीक्षण चला रहा हूं, लेकिन मैं प्रति सेकंड ~ 2000 से अधिक अनुरोध नहीं कर सकता (k6 परिणामों को देखते हुए)। मैं सोच रहा था कि क्या यह k6 है जो किसी प्रकार के बैक-प्रेशर तंत्र को लागू करता है यदि यह समझता है कि मेरा सिस्टम "धीमा" है या यदि कुछ अन्य कारण हैं तो मैं उस सीमा को पार नहीं कर सकता।

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

जैसे निम्नलिखित परीक्षण समान हैं, केवल परिवर्तन VU की संख्या है। मैं सभी परीक्षण k6 cloud पर चलाता हूं।

साझा पैरामीटर:

60 api calls (I have a single http.batch with 60 api calls)
Iterations: 100
Executor: per-vu-iterations

यहां मुझे 547 अनुरोध/एस मिले:

VUs: 10 (60.000 calls with an avg response time of 108ms)

यहाँ मुझे 1.051,67 अनुरोध/सेकंड मिले:

VUs: 20 (120.000 calls with an avg response time of 112 ms)

मुझे 1.794,33 अनुरोध/सेकंड मिले:

VUs: 40 (240.000 calls with an avg response time of 134 ms)

यहाँ मुझे 2.060,33 अनुरोध/सेकंड मिले:

VUs: 80 (480.000 calls with an avg response time of 238 ms)

यहाँ मुझे 2.223,33 अनुरोध/सेकंड मिले:

VUs: 160 (960.000 calls with an avg response time of 479 ms)

यहाँ मुझे 2.102,83 शिखर अनुरोध/सेक मिले:

VUs: 200 (1.081.380 calls with an avg response time of 637 ms) // I reach the max duration here, that's why he stop

मैं जो उम्मीद कर रहा था वह यह है कि यदि मेरा सिस्टम इतने अनुरोधों को संभाल नहीं सकता है तो मुझे बहुत सी टाइमआउट त्रुटियां देखनी होंगी लेकिन मुझे कोई भी नहीं दिख रहा है। मैं जो देख रहा हूं वह यह है कि सभी एपीआई कॉल निष्पादित की जाती हैं और कोई त्रुटि वापस नहीं आती है। क्या कोई मेरी मदद कर सकता है ?

2
lucataglia 2 नवम्बर 2021, 21:26

1 उत्तर

सबसे बढ़िया उत्तर

K6 - या अधिक विशेष रूप से, आपके VUs - कोड को सिंक्रोनस रूप से निष्पादित करते हैं, आपके द्वारा प्राप्त की जा सकने वाली थ्रूपुट की मात्रा पूरी तरह से इस बात पर निर्भर करती है कि आप जिस सिस्टम के साथ इंटरैक्ट कर रहे हैं, वह कितनी जल्दी प्रतिक्रिया करता है।

आइए इस स्क्रिप्ट को एक उदाहरण के रूप में लें:

import http from 'k6/http';

export default function() {
  http.get("https://httpbin.org/delay/1");
}

यहां समापन बिंदु को उद्देश्यपूर्ण ढंग से प्रतिक्रिया देने के लिए 1 सेकंड का समय लेने के लिए डिज़ाइन किया गया है। निर्यात किए गए डिफ़ॉल्ट फ़ंक्शन में कोई अन्य कोड नहीं है। क्योंकि प्रत्येक VU http.get स्टेटमेंट से आगे बढ़ने से पहले एक प्रतिक्रिया (या एक टाइमआउट) की प्रतीक्षा करेगा, प्रत्येक VU के लिए अधिकतम थ्रूपुट एक बहुत ही अनुमानित 1 HTTP अनुरोध/सेकंड होगा।

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

एकमात्र ऐसी स्थिति जहां नहीं मामला हो सकता है जब सिस्टम चल रहा k6 हार्डवेयर संसाधनों (आमतौर पर CPU समय) से बाहर हो जाता है। यह एक ऐसी चीज है जिस पर आपको हमेशा ध्यान देना चाहिए।

यदि आप k6 OSS का उपयोग कर रहे हैं, तो आप उतने VU (समवर्ती थ्रेड्स) तक स्केल कर सकते हैं, जितने आपका सिस्टम संभाल सकता है। आप http.batch का उपयोग प्रत्येक VU के भीतर के साथ-साथ कई अनुरोधों को बंद करने के लिए भी कर सकते हैं (विवरण तब भी अवरुद्ध रहेगा जब तक कि सभी प्रतिक्रियाएं प्राप्त नहीं हो जाती)। यह अतिरिक्त VU को स्पिन करने की तुलना में थोड़ा कम ओवरहेड हो सकता है।

1
Tom 4 नवम्बर 2021, 18:11