🧕🏼 🆗 🤲🏾 टिड्डी के साथ लोड परीक्षण 🧡 📺 👩‍🌾

लोड परीक्षण मांग में इतना व्यापक नहीं है और अन्य प्रकार के परीक्षण के रूप में व्यापक है - इस तरह के परीक्षण का संचालन करने के लिए बहुत सारे उपकरण नहीं हैं, लेकिन साधारण और सुविधाजनक को आमतौर पर एक हाथ की उंगलियों पर गिना जा सकता है।

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

और अब, दो अलग-अलग परियोजनाओं में परीक्षण की सफलता से प्रेरित होकर, मैंने अपेक्षाकृत सरल और सुविधाजनक सॉफ़्टवेयर - टिड्डी के बारे में जानकारी साझा करने का निर्णय लिया

उन लोगों के लिए जो कट के नीचे जाने के लिए बहुत आलसी हैं, मैंने एक वीडियो रिकॉर्ड किया है:

यह क्या है

ओपन सोर्स टूल जो आपको पाइथन कोड के साथ लोड परिदृश्यों को निर्दिष्ट करने की अनुमति देता है जो वितरित भार का समर्थन करता है और, जैसा कि लेखकों का दावा है, का इस्तेमाल बैटलफेल्ड सीरीज़ ऑफ़ गेम्स (तुरंत मनोरम) के लिए बैटलॉग तनाव परीक्षण के लिए किया गया था।

पेशेवरों से:

कॉपी-पेस्ट उदाहरण सहित सरल प्रलेखन। आप लगभग किसी भी प्रोग्रामिंग कौशल के साथ परीक्षण शुरू कर सकते हैं।
"हुड के तहत" अनुरोध पुस्तकालय (लोगों के लिए HTTP) का उपयोग करता है। इसका प्रलेखन एक विस्तारित धोखा पत्र और डेबिट परीक्षण के रूप में इस्तेमाल किया जा सकता है
अजगर का समर्थन - मुझे भाषा पसंद है
पिछला पैराग्राफ रनिंग टेस्ट के लिए क्रॉस-प्लेटफॉर्म देता है
परीक्षा परिणाम प्रदर्शित करने के लिए स्वयं फ्लास्क वेब सर्वर

Minuses की:

कोई कब्जा नहीं और फिर से खेलना - सभी हाथ
पिछले पैराग्राफ का परिणाम - आपको मस्तिष्क की आवश्यकता है। Postman के साथ, आपको यह समझने की आवश्यकता है कि HTTP कैसे काम करता है।
न्यूनतम प्रोग्रामिंग कौशल की जरूरत है
रैखिक लोड मॉडल - जो तुरंत उपयोगकर्ताओं को "गॉस के अनुसार" उत्पन्न करने के लिए अपसेट करता है

परीक्षण की प्रक्रिया

कोई भी परीक्षण एक जटिल कार्य है जिसके लिए नियोजन, तैयारी, कार्यान्वयन की निगरानी और परिणामों के विश्लेषण की आवश्यकता होती है। तनाव परीक्षण के दौरान, यदि संभव हो, तो परिणाम को प्रभावित करने वाले सभी संभावित डेटा एकत्र करना संभव और आवश्यक है:

सर्वर हार्डवेयर (CPU, RAM, ROM)
सर्वर सॉफ्टवेयर (ओएस, सर्वर संस्करण, जावा, .NET, आदि, डेटाबेस और डेटा की राशि ही, सर्वर और परीक्षण अनुप्रयोग लॉग)
नेटवर्क बैंडविड्थ
प्रॉक्सी सर्वर, लोड बैलेंसर और डीडीओएस सुरक्षा की उपस्थिति
लोड परीक्षण डेटा (उपयोगकर्ताओं की संख्या, औसत प्रतिक्रिया समय, प्रति सेकंड अनुरोधों की संख्या)

नीचे वर्णित उदाहरणों को ब्लैक-बॉक्स कार्यात्मक लोड परीक्षण के रूप में वर्गीकृत किया जा सकता है। यहां तक कि परीक्षण के तहत आवेदन के बारे में कुछ भी जाने और लॉग्स तक पहुंच के बिना, हम इसके प्रदर्शन को माप सकते हैं।

शुरू करने से पहले

व्यवहार में लोड परीक्षणों का परीक्षण करने के लिए, मैंने स्थानीय रूप से सरल वेब सर्वर https://github.com/typicode/json-server को तैनात किया। मैं उसके लिए लगभग सभी उदाहरण दूंगा। मैंने सर्वर के लिए एक ऑनलाइन उदाहरण से डेटा लिया - https://jsonplaceholder.typicode.com/
इसे चलाने के लिए, नोडज की आवश्यकता होती है।

स्पष्ट स्पॉइलर : सुरक्षा परीक्षण के साथ - यह ऑनलाइन सेवाओं को लोड किए बिना, स्थानीय स्तर पर बिल्लियों पर तनाव परीक्षण के साथ प्रयोग करने के लिए बेहतर है ताकि आपको प्रतिबंधित न किया जाए।

शुरू करने के लिए, पायथन की भी आवश्यकता है - सभी उदाहरणों में मैं संस्करण 3.6 का उपयोग करूँगा, साथ ही टिड्डे (लेखन के समय, संस्करण 0.9.0)। इसे कमांड के साथ इंस्टॉल किया जा सकता है

python -m pip install locustio

स्थापना विवरण आधिकारिक दस्तावेज में पाया जा सकता है।

एक उदाहरण पार्स करना

आगे हमें एक परीक्षण फ़ाइल की आवश्यकता है। मैंने प्रलेखन से एक उदाहरण लिया, क्योंकि यह बहुत ही सरल और सीधा है:

 from locust import HttpLocust, TaskSet def login(l): l.client.post("/login", {"username":"ellen_key", "password":"education"}) def logout(l): l.client.post("/logout", {"username":"ellen_key", "password":"education"}) def index(l): l.client.get("/") def profile(l): l.client.get("/profile") class UserBehavior(TaskSet): tasks = {index: 2, profile: 1} def on_start(self): login(self) def on_stop(self): logout(self) class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 5000 max_wait = 9000

वह सब है! परीक्षण शुरू करने के लिए यह वास्तव में पर्याप्त है! शुरू करने से पहले एक उदाहरण देखते हैं।

आयात लंघन, बहुत शुरुआत में हम एक पंक्ति से 2 लगभग समान लॉगिन और लॉगआउट फ़ंक्शन देखते हैं। l.client - एक HTTP सत्र ऑब्जेक्ट जिसके साथ हम एक लोड बनाएंगे। हम POST विधि का उपयोग करते हैं, जो अनुरोध लाइब्रेरी में लगभग एक समान है। लगभग - क्योंकि इस उदाहरण में हम पहले तर्क के रूप में एक पूर्ण URL नहीं, बल्कि इसका एक हिस्सा - एक विशिष्ट सेवा से गुजर रहे हैं।

दूसरा तर्क डेटा को पास करता है - और मैं मदद नहीं कर सकता लेकिन ध्यान दें कि पायथन शब्दकोशों का उपयोग करना बहुत सुविधाजनक है, जो स्वचालित रूप से आगजनी कर रहे हैं

आप यह भी नोट कर सकते हैं कि हम किसी भी तरह से अनुरोध के परिणाम को संसाधित नहीं करते हैं - यदि यह सफल होता है, तो परिणाम (उदाहरण के लिए, कुकीज़) इस सत्र में सहेजे जाएंगे। यदि कोई त्रुटि होती है, तो इसे रिकॉर्ड किया जाएगा और लोड के बारे में आंकड़ों में जोड़ा जाएगा।

अगर हम यह जानना चाहते हैं कि क्या हमने अनुरोध को सही तरीके से लिखा है, तो हम इसे हमेशा निम्नानुसार देख सकते हैं:

 import requests as r response=r.post(base_url+"/login",{"username":"ellen_key","password":"education"}) print(response.status_code)

मैंने केवल base_url वैरिएबल जोड़ा है, जिसमें परीक्षण किए जा रहे संसाधन का पूरा पता होना चाहिए।

अगले कुछ कार्य क्वेरी हैं, जो एक लोड बनाएंगे। फिर से, हमें सर्वर प्रतिक्रिया को संसाधित करने की आवश्यकता नहीं है - परिणाम तुरंत आंकड़ों पर जाएंगे।

इसके बाद UserBehavior class (क्लास का नाम कोई भी हो सकता है) है। जैसा कि नाम का अर्थ है, यह परीक्षण के तहत आवेदन के वैक्यूम में एक गोलाकार उपयोगकर्ता के व्यवहार का वर्णन करेगा। हम कार्य संपत्ति को उन विधियों का एक शब्दकोष देते हैं जो उपयोगकर्ता कॉल करेगा और कॉल की उनकी आवृत्ति। अब, इस तथ्य के बावजूद कि हम नहीं जानते कि कौन सा फ़ंक्शन और किस क्रम में प्रत्येक उपयोगकर्ता कॉल करेगा - उन्हें यादृच्छिक रूप से चुना जाता है, हम गारंटी देते हैं कि इंडेक्स फ़ंक्शन को प्रोफ़ाइल फ़ंक्शन की तुलना में औसतन 2 गुना अधिक बार बुलाया जाएगा।

व्यवहार के अतिरिक्त, पैरेंट क्लास टास्कसेट आपको 4 फ़ंक्शन निर्दिष्ट करने की अनुमति देता है जो परीक्षणों से पहले और बाद में किए जा सकते हैं। कॉल का क्रम निम्नानुसार होगा:

सेटअप - यूजरबहेवियर (टास्कसेट) की शुरुआत में 1 बार कहा जाता है - यह उदाहरण में नहीं है
on_start - स्टार्टअप पर लोड के प्रत्येक नए उपयोगकर्ता द्वारा 1 बार कॉल किया गया
कार्य - कार्यों का निष्पादन स्वयं
on_stop - परीक्षण समाप्त होने पर प्रत्येक उपयोगकर्ता द्वारा एक बार कॉल किया जाता है
अश्रु - टास्कसेट से बाहर निकलने पर 1 बार कहा जाता है - यह भी उदाहरण में नहीं है

यहां यह उल्लेखनीय है कि उपयोगकर्ता के व्यवहार को घोषित करने के 2 तरीके हैं: पहले से ही ऊपर दिए गए उदाहरण में पहले ही संकेत दिया गया है - फ़ंक्शन अग्रिम में घोषित किए गए हैं। दूसरा तरीका यह है कि UserBehavior वर्ग के अंदर सीधे तरीकों की घोषणा करें:

 from locust import HttpLocust, TaskSet, task class UserBehavior(TaskSet): def on_start(self): self.client.post("/login", {"username":"ellen_key", "password":"education"}) def on_stop(self): self.client.post("/logout", {"username":"ellen_key", "password":"education"}) @task(2) def index(self): self.client.get("/") @task(1) def profile(self): self.client.get("/profile") class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 5000 max_wait = 9000

इस उदाहरण में, उपयोगकर्ता फ़ंक्शन और उनके कॉल की आवृत्ति कार्य एनोटेशन का उपयोग करके सेट की गई है। कार्यात्मक रूप से, कुछ भी नहीं बदला है।

उदाहरण से अंतिम वर्ग WebsiteUser है (कक्षा का नाम कोई भी हो सकता है)। इस वर्ग में, हम उपयोगकर्ता व्यवहार मॉडल UserBehavior *** + को परिभाषित करते हैं, साथ ही प्रत्येक उपयोगकर्ता द्वारा अलग-अलग कार्यों के लिए कॉल के बीच न्यूनतम और अधिकतम प्रतीक्षा समय। इसे स्पष्ट करने के लिए, यहां बताया गया है कि इसकी कल्पना कैसे करें:

शुरुआत हो रही है

सर्वर चलाएं, जिस प्रदर्शन का हम परीक्षण करेंगे:

 json-server --watch sample_server/db.json

हम उदाहरण फ़ाइल को भी संशोधित करते हैं ताकि यह सेवा का परीक्षण कर सके, लॉगिन और लॉगआउट को हटा सके, उपयोगकर्ता व्यवहार सेट कर सके:

काम शुरू होने पर मुख्य पृष्ठ 1 बार खोलें
सभी x2 पदों की एक सूची प्राप्त करें
पहली पोस्ट X1 पर एक टिप्पणी लिखें

 from locust import HttpLocust, TaskSet, task class UserBehavior(TaskSet): def on_start(self): self.client.get("/") @task(2) def posts(self): self.client.get("/posts") @task(1) def comment(self): data = { "postId": 1, "name": "my comment", "email": "test@user.habr", "body": "Author is cool. Some text. Hello world!" } self.client.post("/comments", data) class WebsiteUser(HttpLocust): task_set = UserBehavior min_wait = 1000 max_wait = 2000

कमांड प्रॉम्प्ट पर प्रारंभ करने के लिए, कमांड चलाएँ

 locust -f my_locust_file.py --host=http://localhost:3000

जहाँ मेजबान परीक्षित संसाधन का पता है। यह उसके लिए है कि परीक्षण में संकेतित सेवाओं के पते जोड़े जाएंगे।

यदि परीक्षण में कोई त्रुटि नहीं है, तो लोड सर्वर शुरू हो जाएगा और http: // localhost: 8089 / पर उपलब्ध होगा।

जैसा कि आप देख सकते हैं, जिस सर्वर पर हम परीक्षण कर रहे हैं, वह यहां इंगित किया गया है - यह इस URL पर है कि परीक्षण फ़ाइल से सेवाओं के पते जोड़े जाएंगे।

साथ ही यहाँ हम लोड के लिए उपयोगकर्ताओं की संख्या और प्रति सेकंड उनकी वृद्धि का संकेत कर सकते हैं।
बटन पर, हम लोड शुरू करते हैं!

परिणाम

एक निश्चित समय के बाद, हम परीक्षण को रोकते हैं और पहले परिणामों पर एक नज़र डालते हैं:

जैसी कि उम्मीद थी, शुरू में 10 में से प्रत्येक उपयोगकर्ता मुख्य पृष्ठ पर गए
औसतन पदों की सूची एक टिप्पणी लिखने की तुलना में 2 गुना अधिक बार खोली गई थी
प्रत्येक ऑपरेशन के लिए औसत और औसत प्रतिक्रिया समय है, प्रति सेकंड ऑपरेशन की संख्या पहले से ही उपयोगी डेटा है, भले ही अब इसे ले लो और आवश्यकताओं से अपेक्षित परिणाम के साथ तुलना करें

दूसरे टैब पर, आप वास्तविक समय में लोड ग्राफ़ देख सकते हैं। यदि सर्वर एक निश्चित लोड पर दुर्घटनाग्रस्त हो जाता है या उसका व्यवहार बदल जाता है, तो यह तुरंत ग्राफ पर दिखाई देगा।

तीसरे टैब पर, आप त्रुटियों को देख सकते हैं - मेरे मामले में, यह एक क्लाइंट त्रुटि है। लेकिन अगर सर्वर 4XX या 5XX त्रुटि देता है, तो इसका पाठ यहां लिखा जाएगा
यदि आपके पाठ के कोड में कोई त्रुटि होती है, तो वह अपवाद टैब में आ जाएगी। अब तक मुझे कोड में प्रिंट () कमांड का उपयोग करने से संबंधित सबसे आम त्रुटि है - यह लॉग इन करने का सबसे अच्छा तरीका नहीं है :)

अंतिम टैब पर, आप सीएसवी प्रारूप में सभी परीक्षा परिणाम डाउनलोड कर सकते हैं

क्या ये परिणाम प्रासंगिक हैं? चलिए इसका पता लगाते हैं। सबसे अधिक बार, प्रदर्शन की आवश्यकताएं (यदि कोई भी सभी में बताई गई है) कुछ इस तरह से ध्वनि करती है: औसत पृष्ठ लोड समय (सर्वर प्रतिक्रिया) एम उपयोगकर्ताओं के भार के साथ एन सेकंड से कम होना चाहिए। वास्तव में निर्दिष्ट नहीं कि उपयोगकर्ता क्या करें। और मैं इसके लिए टिड्डे को पसंद करता हूं - यह उपयोगकर्ताओं की एक विशिष्ट संख्या की गतिविधि बनाता है जो उपयोगकर्ताओं से अपेक्षित अपेक्षित कार्यों को बेतरतीब ढंग से करते हैं।

अगर हमें अलग-अलग लोड पर सिस्टम के व्यवहार को मापने के लिए एक बेंचमार्क करने की आवश्यकता है, तो हम व्यवहार के कई वर्ग बना सकते हैं और विभिन्न भारों पर कई परीक्षण कर सकते हैं।

यह एक शुरुआत के लिए पर्याप्त है। यदि आपको लेख पसंद आया है, तो मैं इसके बारे में लिखने की योजना बना रहा हूं:

जटिल परीक्षण परिदृश्य जिसमें एक चरण के परिणाम निम्नलिखित में उपयोग किए जाते हैं
सर्वर प्रतिक्रिया प्रसंस्करण, के रूप में अगर HTTP 200 OK आ गया है तो भी यह गलत हो सकता है
स्पष्ट कठिनाइयों का सामना करना पड़ सकता है और उनके आसपास कैसे पहुंचें
UI का उपयोग किए बिना परीक्षण
वितरित लोड परीक्षण