प्रेशर टेस्ट

प्रेशर टेस्ट के परिणाम पर कौन-कौन से कारकों का प्रभाव होता है?

सर्वर तक प्रेशर मशीन के नेटवर्क देरी (सुझाव दिया गया है कि इंटरनेट या अपने ही नेटवर्क पर दबाव टेस्ट करें)
सर्वर तक प्रेशर मशीन की बैंडविड्थ (सुझाव दिया गया है कि इंटरनेट या अपने ही नेटवर्क पर दबाव टेस्ट करें)
क्या HTTP keep-alive चालू है (सुझाव दिया गया है कि इसे चालू करें)
क्या परावर्तन संख्या पर्याप्त है (बाहरी नेटवर्क पर टेस्ट करते समय, अधिक समानता को संभावित रूप से बढ़ाने का प्रयास करें)
क्या सर्वर प्रक्रिया संख्या विवेकपूर्ण है (हैलोवर्ल्ड व्यापार प्रक्रिया संख्या को सुझाव दिया गया है कि सीपीयू संख्या के समान हो, डेटाबेस व्यापार प्रक्रिया संख्या को सीपीयू के चार गुना और उससे अधिक सुझाव दिया गया है)
व्यावसायिक स्वयं की प्रदर्शन (उदाहरण के लिए क्या बाहरी डेटाबेस का उपयोग किया जा रहा है)

HTTP keep-alive क्या है?

HTTP Keep-Alive प्रक्रिया एक ऐसी तकनीक है जो एक एकल TCP कनेक्शन पर एकाधिक HTTP अनुरोध और प्रतिक्रियाएँ भेजने के लिए प्रयोग होती है, यह प्रदर्शन परीक्षण के परिणामों पर बड़ा प्रभाव डालती है, keep-alive बंद करने के बाद QPS का विशेष प्रभाव हो सकता है।
वर्तमान में ब्राउज़र सभी डिफ़ॉल्ट रूप से keep-alive को सक्रिय करते हैं, अर्थात ब्राउज़र किसी भी HTTP पते का अनुरोध करने के बाद कनेक्शन को संकेत योजित नहीं करता है, अगले अनुरोध में इस कनेक्शन को पुनः प्रयोग करता है, अच्छे प्रदर्शन के लिए।
दबाव टेस्ट करते समय, keep-alive को सक्रिय करने का सुझाव दिया गया है।

कैसे कीप-एलाइव HTTP चालू करें जब लोड टेस्ट किया जाता है?

यदि एबी प्रोग्राम का उपयोग किया जा रहा है तो -k पैरामीटर जोड़ना चाहिए, उदाहरण के लिए ab -n100000 -c200 -k http://127.0.0.1:8787/।
एपीपोस्ट में कीप-एलाइव को सक्षम करने के लिए जवाबी सिर में गिजीप हैडर लाना चाहिए(एपीपोस्ट की बग, नीचे देखें)।
अन्य लोड टेस्ट प्रोग्राम आम तौर पर डिफ़ॉल्ट रूप से चालू हो जाते हैं।

क्यों बाहरी नेटवर्क के माध्यम से क्यूपीएस बहुत कम है?

बाहरी नेटवर्क देरी बहुत अधिक होने के कारण क्यूपीएस बहुत कम होती है, यह सामान्य घटना है। उदाहरण के लिए, बैदू पेज का लोड टेस्ट करने पर क्यूपीएस संभावित रूप में केवल कुछ दस हो सकती है।
आंतरिक नेटवर्क या स्थानीय मशीन पर लोड टेस्ट करने की सलाह दी जाती है, नेटवर्क देरी के प्रभाव को निकालते हुए।
यदि बाहरी नेटवर्क में लोड टेस्ट करना आवश्यक है, तो बैंडविड्थ को निखारने के लिए समतल संख्या बढ़ाकर पारंगतता (पूर्ण होने की आवश्यकता है) को बढ़ा सकते हैं।
क्योंकि nginx प्रॉक्सी करने के बाद प्रदर्शन में कमी होती है?
nginx को चलाने के लिए सिस्टम संसाधनों की खपत होती है। साथ ही, nginx और webman के बीच संचार भी कुछ संसाधनों की खपत करता है।
हालांकि, सिस्टम संसाधन सीमित होते हैं, और webman सभी सिस्टम संसाधनों को प्राप्त नहीं कर सकता है, इसलिए, पूरे सिस्टम का प्रदर्शन कम हो सकता है।
nginx प्रॉक्सी द्वारा प्रदर्शन पर पड़े असर को कम संभावना होने के लिए, nginx लॉग (access_log off;) को बंद करने का विचार किया जा सकता है,
nginx से webman तक के बीच keep-alive को सक्रिय करने का विचार कर सकते हैं, nginx प्रॉक्सी देखें।

इसके अलावा, https और http की तुलना में अधिक संसाधनों का उपयोग करेगा, क्योंकि https में SSL/TLS हैंडशेक, डेटा एन्क्रिप्शन और डेक्रिप्शन की आवश्यकता होती है,
जिससे पैकेट का आकार बढ़ जाता है और अधिक बैंडविड्थ का उपयोग करता है, ये सब प्रदर्शन में कमी का कारण बन सकते हैं।
अगर टेस्टिंग के लिए शॉर्ट लिंक (HTTP keep-alive सक्रिय नहीं करना) का उपयोग किया जा रहा है, तो हर बार अतिरिक्त SSL/TLS हैंडशेक संचार की आवश्यकता होगी, प्रदर्शन में महत्वपूर्ण कमी आ सकती है।
सुझाव दिया जाता है कि https टेस्टिंग में HTTP keep-alive को सक्रिय करें।

कैसे पता चलेगा कि सिस्टम परफॉर्मेंस की सीमा तक पहुंच गयी है?

सामान्यत: CPU 100% तक पहुंच जाने पर सिस्टम की परफॉर्मेंस सीमा तक पहुंच गयी है। अगर CPU में अभी भी खाली स्थान है, तो यह सिस्टम की सीमा तक पहुंचने का संकेत नहीं है, इस स्थिति में पररवाह करके कंकरेट क्रम बढ़ा सकते हैं ताकि QPS बढ़ा सके।
अगर कंकरेट बढ़ाने से QPS बढ़ाना संभव नहीं है तो शायद webman प्रक्रियाओं की संख्या पर्याप्त नहीं है, कृपया webman प्रक्रियाओं की संख्या को बढ़ा दें। अगर फिर भी बढ़ाव नहीं होता है तो विचार करें कि क्या बैंडविड्थ पर्याप्त है या नहीं।

मेरा परफॉर्मेंस टेस्ट का परिणाम दिखा रहा है कि webman go के gin फ़्रेमवर्क से कम परफ़ॉर्मेंस दे रहा है, ऐसा क्यों?

techempower का परफॉर्मेंस टेस्ट दर्शाता है कि webman सिर्फ प्लेन टेक्स्ट, डेटाबेस क्वेरी, डेटाबेस अपडेट आदि सभी पैरामीटरों में gin से लगभग दोगुना अधिक है। अगर आपके परिणाम अलग हैं तो यह शायद इसका कारण है कि आपने webman में ORM का उपयोग करते हुए प्रमुख परफ़ॉर्मेंस घाटा को समझा नहीं है, कृपया webman+नेटिव PDO और gin+नेटिव SQL का मुकाबला करें।

webman में ORM का उपयोग कितने प्रदर्शन में कमी लाता है?

नीचे दिए गए एक संकट जानकारी है

परिसर
अली बादल 4 कोर 4 जीबी सर्वर, 10 लाख रिकॉर्ड से एक छोटी सी डेटा json वापस लाने के लिए यादृच्छिक जांच।

यदि मूल PDO का उपयोग किया जाता है
webman क्यूपीएस 1.78 हजार है

अगर लारवेल का Db::table() उपयोग किया जाता है
webman क्यूपीएस 0.94 हजार हो जाता है

यदि लारवेल का मॉडल का उपयोग किया जाता है
webman क्यूपीएस 0.72 हजार हो जाता है

thinkORM के परिणाम समान रूप से हैं, कोई बड़ा अंतर नहीं है।

सुझाव
यद्यपि ORM का उपयोग प्रदर्शन में गिरावट लाता है, लेकिन अधिकांश व्यावसायिक के लिए यह पर्याप्त है। हमें उपभोक्ता मूल्यांकन, रखरखाव, प्रदर्शन आदि कई मापदंडों में संतुलन स्थापित करना चाहिए, बल्कि सिर्फ प्रदर्शन की पीछा करनी चाहिए।
एपीपोस्ट का दबाव परीक्षण मॉड्यूल में एक समस्या होती है, अगर सर्वर gzip हेडर नहीं भेजता है तो keep-alive को बनाए रखना संभव नहीं होता है, जिससे प्रदर्शन में बड़ी गिरावट आती है।
समाधान के रूप में, डेटा को संपीड़ित करके और gzip हेडर जोड़कर डेटा वापस भेजना चाहिए, जैसे
<?php
namespace app\controller;
class IndexController
{
public function index()
{
return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
}
}
इसके अलावा, कुछ स्थितियों में एपीपोस्ट संतुष्टि प्रदान नहीं करता है, यह संदर्भ में होता है कि बराबर की एक ही संवर्धना के साथ, एबी की तुलना में एपीपोस्ट के करीब 50% कम QPS होता है।
प्रेशर टेस्टिंग के लिए सुझाव दिया जाता है कि एब, wrk या अन्य व्यावसायिक प्रेशर परीक्षण सॉफ़्टवेयर का उपयोग करें, न कि एपीपोस्ट का उपयोग करें।

सही प्रक्रिया संख्या सेट करें

webman डिफ़ॉल्ट रूप से cpu*4 प्रक्रियाएँ शुरू करता है। वास्तविकता में नेटवर्क आईओ के बिना helloworld व्यवसाय की लोड टेस्ट प्रक्रिया संख्या को cpu के कर्ण संख्या के समान होना चाहिए, क्योंकि इससे प्रक्रिया बदलने का खर्च कम हो सकता है।
यदि डेटाबेस, रेडिस आदि सहित ब्लॉकड आईओ व्यवसाय है, तो प्रक्रियाओं की संख्या को cpu के 3-8 गुणा के रूप में सेट किया जा सकता है, क्योंकि इस समय अधिक प्रक्रियाएं आवश्यक होती हैं जो अधिक समयांतरण का खर्च बढ़ा सकती है।

कुछ संकेत मान

क्लाउड सर्वर 4 कोर 4जी 16 प्रक्रियाएँ लॉकल/इंटरनेट लोड टेस्ट करें

-	कीप-एलाइव सक्षम करें	कीप-एलाइव नहीं करें
हैलो वर्ल्ड	8-16 हजार क्यूपीएस	1-3 हजार क्यूपीएस
डेटाबेस सिंगल क्वेरी	1-2 हजार क्यूपीएस	1 हजार क्यूपीएस

तीसरा पक्ष techempower लोड टेस्ट डेटा

परख परीक्षण कमांड उदाहरण

# 100000 अनुरोध 200 समवर्धन keep-alive सक्षम करें
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 अनुरोध 200 समवर्धन keep-alive बंद करें
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 समवर्धन परीक्षण 10 सेकंड keep-alive सक्षम करें (डिफ़ॉल्ट)
wrk -c 200 -d 10s http://example.com