दबाव परीक्षण

दबाव परीक्षण के परिणामों को किन कारकों से प्रभावित किया जाता है?

दबाव मशीन से सर्वर तक नेटवर्क लेटेंसी (स्थानीय नेटवर्क या स्थानीय मशीन पर परीक्षण करने की सिफारिश की जाती है)
दबाव मशीन से सर्वर तक बैंडविड्थ (स्थानीय नेटवर्क या स्थानीय मशीन पर परीक्षण करने की सिफारिश की जाती है)
क्या HTTP keep-alive सक्षम है (सक्रिय करने की सिफारिश की जाती है)
क्या समांतर संख्या पर्याप्त है (बाहरी नेटवर्क परीक्षण में ज्यादा समांतरता को सक्षम करने की कोशिश करें)
सर्वर पक्ष की प्रक्रिया संख्या क्या उचित है (helloworld सेवा प्रक्रिया संख्या की सिफारिश CPU संख्या के समान है, डेटाबेस सेवा प्रक्रिया संख्या की सिफारिश CPU के चार गुना या उससे अधिक है)
व्यवसाय की अपनीसिद्धांत प्रदर्शन (जैसे कि क्या बाहरी नेटवर्क डेटाबेस का उपयोग किया गया है)

HTTP keep-alive क्या है?

HTTP Keep-Alive तंत्र एक तकनीक है जिसका उपयोग एकल TCP कनेक्शन पर कई HTTP अनुरोधों और प्रतिक्रियाओं को भेजने के लिए किया जाता है, इसका प्रदर्शन परीक्षण परिणामों पर बहुत प्रभाव पड़ता है, keep-alive बंद करने पर QPS कई गुना कम हो सकता है।
वर्तमान में सभी ब्राउज़र डिफ़ॉल्ट रूप से keep-alive को सक्षम करते हैं, यानी कि जब ब्राउज़र किसी विशेष HTTP पते पर पहुंचता है, तो वह कनेक्शन को अस्थायी रूप से बंद नहीं करता है, अगली बार अनुरोध करते समय इस कनेक्शन का पुन: उपयोग करता है, ताकि प्रदर्शन को बढ़ावा मिल सके।
दबाव परीक्षण के दौरान keep-alive को सक्षम करने की सिफारिश की जाती है।
इसके अलावा, यदि keep-alive को सक्षम नहीं किया जाता है, तो क्लाइंट के स्थानीय पोर्ट जल्दी से timewait स्थिति में समाप्त हो जाएंगे, और यह सामान्यतः एक निश्चित संख्या (लगभग 28,000 के आसपास) से अधिक कुल अनुरोध संख्या के आधार पर विफल अनुरोध प्रदर्शित करेगा।

दबाव परीक्षण के दौरान HTTP keep-alive कैसे सक्षम करें?

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

बाहरी नेटवर्क परीक्षण के द्वारा QPS इतना कम क्यों है?

बाहरी नेटवर्क में उच्च लेटेंसी के कारण QPS कम होना सामान्य है। उदाहरण के लिए, baidu पृष्ठ के दबाव परीक्षण में QPS केवल कुछ दर्जन हो सकता है।
स्थानीय नेटवर्क या खुद के मशीन पर दबाव परीक्षण करने की सिफारिश की जाती है, ताकि नेटवर्क लेटेंसी के प्रभाव को समाप्त किया जा सके।
यदि आप किसी बाहरी नेटवर्क पर दबाव परीक्षण करने पर मजबूर हैं, तो थ्रूपुट बढ़ाने के लिए समांतर संख्या बढ़ाने पर विचार करें (बैंडविड्थ पर्याप्त होने की आवश्यकता है)।

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 कोर 4G, स्थानीय MySQL डेटाबेस, 100,000 रिकॉर्ड में से एक डेटा को यादृच्छिक रूप से खोजकर JSON वापस करते हुए, स्थानीय मशीन पर परीक्षण किया गया।

यदि आप मूल PDO का उपयोग करते हैं
webman QPS 1.78 लाख है।

यदि आप laravel के Db::table() का उपयोग करते हैं
webman QPS 0.94 लाख QPS पर गिर जाता है।

यदि आप laravel के Model का उपयोग करते हैं
webman QPS 0.72 लाख QPS पर गिर जाता है।

thinkORM के परिणाम समान हैं, बहुत अधिक भिन्नता नहीं है।

सूचना
हालांकि ORM का उपयोग करने से प्रदर्शन में कमी आएगी, लेकिन 99% व्यवसायों के लिए प्रदर्शन पहले से ही पर्याप्त है, यदि आप ठीक उस 1% में हैं तो आप CPU या सर्वर को बढ़ाकर इस समस्या को हल कर सकते हैं।
हमें विकास कुशलता, रखरखावियता, प्रदर्शन आदि कई मापदंडों के बीच एक संतुलन बिंदु प्राप्त करना चाहिए, न कि केवल प्रदर्शन का पीछा करना चाहिए।

क्यों apipost से दबाव परीक्षण पर QPS बहुत कम है?

apipost के दबाव परीक्षण मॉड्यूल में एक बग है, यदि सर्वर gzip हेडर वापस नहीं करता है तो keep-alive को बनाए नहीं रखा जा सकता, जिसके कारण प्रदर्शन में भारी कमी आती है।
समस्या को हल करने के लिए, प्रतिक्रिया करते समय डेटा को संकुचित करें और gzip हेडर जोड़ें, जैसे कि

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

इसके अतिरिक्त, कुछ स्थितियों में, apipost संतोषजनक दबाव नहीं दे सकता है, जो समान समांतरता पर, apipost की तुलना में ab द्वारा लगभग 50% कम QPS के रूप में प्रदर्शित होता है।
दबाव परीक्षण के लिए ab, wrk या अन्य पेशेवर दबाव परीक्षण सॉफ़्टवेयर का उपयोग करने की सिफारिश की जाती है, na कि apipost का।

उपयुक्त प्रक्रिया संख्या सेट करना

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

दबाव परीक्षण के लिए कुछ संदर्भ सीमा

क्लाउड सर्वर 4 कोर 4G 16 प्रक्रियाएँ स्थानीय मशीन/स्थानीय नेटवर्क परीक्षण

-	keep-alive सक्षम	keep-alive निष्क्रिय
हेल्लो वर्ल्ड	8-16 लाख QPS	1-3 लाख QPS
डेटाबेस एकल क्वेरी	1-2 लाख QPS	1 लाख QPS

थर्ड-पार्टी 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