OpenResty FAQ | टेस्टिंग के लिए नेटवर्क संरचना, SSL-संबंधित सुविधाएँ, DSL, `ab` टूल

OpenResty लेख श्रृंखला अब तक अपडेट हो चुकी है, और हमने टेस्टिंग के बारे में सीखने का हिस्सा पूरा कर लिया है। बधाई हो कि आप पीछे नहीं रहे, सक्रिय रूप से सीख रहे हैं और अभ्यास कर रहे हैं, और अपने विचारों को उत्साहपूर्वक साझा कर रहे हैं।

टिप्पणियों में उठाए गए कई सवाल मूल्यवान हैं, और कुछ अधिक विशिष्ट और दिलचस्प सवालों को आज के प्रश्नोत्तर के रूप में विशेष रूप से चुना गया है।

आइए आज इन पांच सवालों पर एक नजर डालते हैं।

प्रश्न 1: टेस्टिंग के लिए नेटवर्क संरचना कैसे बनाएं?

प्रश्न: क्या wrk चलाने वाले क्लाइंट को एक्स्ट्रा नेट पर मशीन पर रखा जाना चाहिए या सर्वर के साथ एक ही LAN पर मशीन पर? इन दोनों में से कौन सा परफॉर्मेंस टेस्टिंग के लिए अधिक सार्थक है?

उत्तर: वेब-संबंधित सेवाओं के परीक्षण के लिए, सही टेस्टिंग टूल चुनना केवल एक अच्छी शुरुआत है, और टेस्टिंग के लिए नेटवर्क संरचना कैसे बनाई जाए, यह भी एक आवश्यक हिस्सा है।

आम तौर पर, हम सेवा की परफॉर्मेंस सीमाओं का परीक्षण करना चाहते हैं, सभी नेटवर्क हस्तक्षेपों को बाहर करते हुए। इस उद्देश्य के लिए, हम दो तरीकों से नेटवर्क बना सकते हैं ताकि स्ट्रेस टेस्ट किया जा सके।

पहला तरीका है कि wrk और सर्वर एप्लिकेशन को एक ही मशीन पर डिप्लॉय किया जाए जिसकी परफॉर्मेंस अच्छी हो। उदाहरण के लिए, हम NGINX में आठ वर्कर्स शुरू कर सकते हैं और शेष CPU संसाधनों को wrk के बीच विभाजित कर सकते हैं, इसलिए केवल स्थानीय नेटवर्क संचार होगा, जिससे नेटवर्क का प्रभाव कम से कम होगा।

दूसरा तरीका है कि एक समर्पित राउटर के साथ एक LAN बनाया जाए और wrk वाली मशीन को सर्वर वाली मशीन से जोड़ा जाए।

आपको मौजूदा नेटवर्क में सीधे टेस्ट करने की सलाह नहीं दी जाती है क्योंकि अधिकांश नेटवर्क में स्विच और फायरवॉल होते हैं, जो बड़े ट्रैफिक वॉल्यूम के स्ट्रेस टेस्टिंग को सीमित कर सकते हैं और टेस्ट परिणामों को गलत बना सकते हैं।

इसके अलावा, मैं परफॉर्मेंस टेस्टिंग टूल्स के बारे में कुछ और बातें कहना चाहूंगा। पहला, परफॉर्मेंस टेस्टिंग टूल्स में Coordinated Omission समस्या हो सकती है, जिस पर आपको टूल के लेटेंसी डेटा का विश्लेषण करते समय विशेष ध्यान देना चाहिए।

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

प्रश्न 2: क्या test::nginx SSL-संबंधित सुविधाओं का परीक्षण कर सकता है?

प्रश्न: क्या test::nginx के साथ SSL-संबंधित सुविधाओं का परीक्षण करना असंभव है?

उत्तर: ऐसा नहीं है। test::nginx SSL-संबंधित सुविधाओं का परीक्षण कर सकता है; आप ssl.t को संदर्भित कर सकते हैं। यह टेस्ट केस फाइल SSL सर्टिफिकेट की पूरी प्रक्रिया का परीक्षण करती है। पहले, जैसा कि आप देख सकते हैं, टेस्ट केस Lua कोड का उपयोग करके स्थानीय सर्टिफिकेट के सार्वजनिक और निजी कुंजी को पढ़ता है; फिर, यह HTTP API के माध्यम से सर्टिफिकेट सेट करता है; अंत में, यह cosocket का उपयोग करके SSL हैंडशेक और पहुंच करता है ताकि यह सत्यापित किया जा सके कि सर्टिफिकेट मान्य है।

वास्तव में, न केवल SSL, बल्कि OpenResty में शामिल सुविधाओं को भी test::nginx का उपयोग करके ओवरराइड किया जा सकता है।

जब आप सुनिश्चित नहीं हैं कि किसी विशेष सुविधा को test::nginx के साथ लागू किया जा सकता है, तो आप पहले lua-nginx-module और अन्य OpenResty ओपन-सोर्स प्रोजेक्ट्स के टेस्ट केस खोज सकते हैं, और आमतौर पर संबंधित उदाहरण मिल जाएंगे। आखिरकार, test::nginx बहुत खेलने योग्य और परिवर्तनशील है, और कुछ अप्रत्याशित संयोजन और ट्रिक्स खोजने के लिए इंतजार कर रहे हैं।

प्रश्न 3: DSL वास्तव में क्या है?

प्रश्न: DSL और test::nginx वास्तव में क्या हैं?

उत्तर: DSL का मतलब है Domain Specific Language। DSL का उद्देश्य सामान्य विकास भाषाओं से अलग है। यह एक सामान्य डोमेन की आवश्यकताओं को हल करने के लिए नहीं है, बल्कि कुछ डोमेन की आवश्यकताओं को हल करने के लिए है। सबसे प्रसिद्ध DSL SQL है, जो डेटाबेस डोमेन में उपयोग की जाने वाली Structured Query Language है।

जहां तक test::nginx की बात है, यह NGINX और OpenResty की टेस्टिंग आवश्यकताओं को पूरा करने के लिए बनाई गई एक DSL है। वास्तव में, OpenResty लेखकों ने कई DSL विचारों का आविष्कार किया है और OpenResty समुदाय के लिए कई नए प्रयास और समाधान लाए हैं। हालांकि, जैसा कि पिछले लेख में उल्लेख किया गया है, DSL एक दोधारी तलवार है, और DSL के मूल्य को मापने का मुख्य मानदंड यह है कि क्या यह अंतिम उपयोगकर्ताओं के लिए उत्पादकता में सुधार ला सकता है।

प्रश्न 4: test::nginx इंस्टॉलेशन समस्या

प्रश्न: git clone करने के बाद, क्या मुझे test::nginx इंस्टॉल करने के लिए निम्नलिखित कमांड चलाने की आवश्यकता है?

cd test-nginx
perl Makefile.PL
make
sudo make install

उत्तर: वास्तव में, ऐसा नहीं है। यहां आप कुछ ओपन-सोर्स प्रोजेक्ट्स को संदर्भित कर सकते हैं।

चरण 1: पैकेज मैनेजर के माध्यम से इंस्टॉल करें

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

चरण 2: नवीनतम test::nginx को git clone करें

git clone https://github.com/openresty/test-nginx.git test-nginx

चरण 3: prove कमांड का उपयोग करते समय test-nginx डायरेक्टरी को शामिल करें

prove -Itest-nginx/lib -r t

जैसा कि मैंने पहले उल्लेख किया है, OpenResty और आसपास के प्रोजेक्ट्स को इंस्टॉल करने के लिए सबसे अच्छे मार्गदर्शक CI में हैं, दस्तावेज़ीकरण में नहीं। यह अन्य प्रोजेक्ट्स से अलग हो सकता है, मुख्य रूप से क्योंकि OpenResty अपने स्वयं के फोर्क या कुछ आसपास के प्रोजेक्ट्स के विशिष्ट संस्करणों को बनाए रखता है और क्योंकि OpenResty भी CI पर बहुत अधिक निर्भर है। इसलिए, आपको OpenResty का उपयोग और परीक्षण उसी तरह करना चाहिए जैसे इसे CI में बनाया गया है, ताकि आधिकारिक एक के साथ स्थिरता सुनिश्चित की जा सके।

प्रश्न 5: क्या ab टेस्ट टूल अच्छा है या नहीं?

प्रश्न: मुझे याद है कि यिचुन झांग ने Google Groups में अक्सर ab को सबसे अच्छा टेस्टिंग टूल के रूप में उल्लेख किया था?

उत्तर: जैसा कि मैंने लेख में उल्लेख किया है, ab टूल फीचर्स के संदर्भ में एक अच्छा परफॉर्मेंस टेस्टिंग टूल नहीं है क्योंकि यह पर्याप्त अनुरोध दबाव उत्पन्न नहीं कर सकता है। हालांकि, सर्वर-साइड प्रोग्राम परफॉर्मेंस अब शक्तिशाली है। हम test::nginx में wrk के बजाय ab का उपयोग करते हैं क्योंकि TEST_NGINX_BENCHMARK मोड में, test::nginx या तो ab या weighttp का उपयोग करता है, HTTP प्रोटोकॉल संस्करण के आधार पर, परफॉर्मेंस टेस्टिंग के लिए टूल के रूप में।

इसके अलावा, मैं चाहूंगा कि आप ध्यान दें कि इंटरनेट प्रौद्योगिकी बहुत तेजी से बदल रही है, और हम में से प्रत्येक को अपने ज्ञान और कौशल को समय पर अपडेट करने की आवश्यकता है। उदाहरण के लिए, मेरी राय में, test::nginx का यह विकल्प अब अपडेट करने की आवश्यकता है, और यिचुन झांग को उस समय wrk के अस्तित्व के बारे में पता नहीं हो सकता है। बेशक, समय के साथ wrk से बेहतर परफॉर्मेंस टेस्टिंग टूल्स आ सकते हैं, और हमें स्वाभाविक रूप से सीखने और चुनने के लिए एक सकारात्मक और खुला दिमाग रखना चाहिए।

आज, मैं मुख्य रूप से उपरोक्त प्रश्नों का उत्तर देता हूं। मुझे आशा है कि संचार और प्रश्नोत्तर के माध्यम से, मैं आपकी मदद कर सकता हूं कि आप जो सीखते हैं, उसे प्राप्त कर सकें। आप इस लेख को आगे भी साझा कर सकते हैं ताकि हम एक साथ संवाद और प्रगति कर सकें।