👷🏻 🛑 👑 स्काईफोर, या बॉट्स में लोड परीक्षण - सर्वर ऑर्डर। भाग २ 👩🏽‍🤝‍👨🏿 💇🏾 🤷🏼

हैलो फिर से, हेबरसियर!

यह स्काईफोर सर्वर का परीक्षण करने वाला दूसरा लेख है। बस के मामले में, मैं आपको याद दिलाता हूं कि Skyforge एक MMORPG है जिसका सर्वर सैकड़ों हजारों खिलाड़ियों के लिए डिज़ाइन किया गया है और जावा में लिखा गया है।
पहले भाग के विपरीत, जो बॉट की भूमिका से संबंधित है, यह लेख तनाव परीक्षण और मैट्रिक्स के बारे में बात करता है।

लोड परीक्षण

हैबर के पाठकों को पता है कि अनुपालन को सत्यापित करने के लिए तनाव परीक्षण सॉफ्टवेयर प्रदर्शन संकेतकों का एक संग्रह है।

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

हमारे पास एक सेवा-उन्मुख वास्तुकला है - इसका मतलब है कि परीक्षण के दौरान सेवाओं की टोपोलॉजी को "मुकाबला" स्थितियों में टोपोलॉजी के साथ मेल खाना चाहिए। सामग्री की मात्रा उस मात्रा के करीब भी होनी चाहिए जो "मुकाबला" पर होगी। सामान्य तौर पर, लोड परीक्षण लघु में एक उत्पादन होता है, जहां वास्तविक उपयोगकर्ताओं के बजाय बॉट होते हैं।

परीक्षण संगठन

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

इस तथ्य के कारण कि हम संसाधनों में सीमित हैं (हमारे पास केवल एक बॉट साइट है), हमें किसी तरह उनके उपयोग को सिंक्रनाइज़ करने की आवश्यकता है। इसलिए, बॉट्स का उपयोग करने वाले सभी परीक्षण एक समर्पित बिल्ड एजेंट पर चलाए जाते हैं।

नाइट बॉट टेस्ट

मुख्य भार परीक्षण, जिसके दौरान सभी सामग्री की जांच की जाती है, रात में 8 घंटे तक चला जाता है। इस अवधि को क्यों चुना गया है? यह प्रायोगिक तौर पर देखा गया कि सबसे गंभीर त्रुटियां 4.5-6 घंटे के मोड़ पर होती हैं, और उन्हें खोजने के लिए, हमें बस इस तरह के लंबे परीक्षणों का संचालन करना होगा। यह इस अंतराल पर है कि एक FullGC ठहराव होता है ( इस घटना के बारे में अधिक ), जिसके खिलाफ लड़ाई भी परीक्षणों का लक्ष्य है। हमने सप्ताहांत में 56 घंटे तक चलने वाले परीक्षणों को लागू करने की योजना बनाई है। लेकिन अभी के लिए, दुर्भाग्य से, ये केवल योजनाएं हैं।

सर्वर

और अब मैं अपने आप को लोड परीक्षण के संगठन पर कुछ सलाह देने की अनुमति दूंगा, यह बात करते हुए कि यह हमारे साथ कैसे काम करता है। हां, मैं समझता हूं कि किसी को ये सुझाव कुख्यात कप्तान के नोट्स प्रतीत होंगे, लेकिन किसी के लिए वे अभी भी उपयोगी हो सकते हैं।

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

आपको यह भी याद रखना होगा कि आधुनिक सर्वर में "हरित वातावरण" या "पावर सेविंग" ऑपरेटिंग मोड हैं। मेरा सुझाव है कि आप प्रोसेसर को पूर्ण प्रदर्शन के लिए सेट करते हुए, उन्हें तुरंत बंद कर दें, क्योंकि सर्वर में आराम करने का समय नहीं होगा, लेकिन इको मोड में परीक्षण के दौरान गैर-मौजूद प्रदर्शन समस्याओं को ठीक करना एक बुरा विचार है।

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

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

दर्ज आंकड़े

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

लोड ग्राफ

मैं हर सुबह एक समान कार्यक्रम देखता हूं। यह आपको लोड को ट्रैक करने की अनुमति देता है। सर्वर लोड 20 मिलीसेकंड के लिए सर्वर के 1 "टिक" के लिए प्रसंस्करण डेटा में खर्च किए गए मिलीसेकंड में समय के अनुपात के बराबर मूल्य है। यदि ग्राफ पर संकेतक एक से अधिक (आदर्श से अधिक) है, तो सब कुछ खराब है, यदि कम है - सब कुछ अच्छा है।

मेमोरी उपयोग ग्राफ

यह मेमोरी उपयोग का एक सामान्य ग्राफ है। यह आपको "कचरा संग्रहकर्ता" के काम का मूल्यांकन करने की अनुमति देता है।

जीसी अनुसूची

यह शायद जावा सर्वर के लिए सबसे महत्वपूर्ण ग्राफ़ में से एक है। यह संभावना नहीं है कि खिलाड़ी पूर्ण कचरा संग्रह के दौरान एक ठहराव को नोटिस नहीं करेंगे। इस पर Y अक्ष के साथ कचरा संग्राहक के एक या दूसरे चरण की अवधि अंकित है।

जिन कुंजियों का उपयोग हम GC प्रदर्शन डेटा एकत्र करने के लिए करते हैं

-वरबोज: जीसी
-XX: + PrintGCTimeStamps
-XX: + PrintGCDetails
-XX: + PrintGCDateStamps
-XX: + PrintTenuringDistribution
-XX: + PrintGCApplicationStontinTime
-XX: + PrintPromotionFailure
-XX: + PrintClassHistogramBeforeFullGC
-XX: + PrintClassHistogramAfterFullGC
-XX: + PrintGCApplicationConcurrentTime

Safepoint पर स्टॉप शेड्यूल

Safepoint जावा वर्चुअल मशीन में वह बिंदु होता है जहां यह हर बार रुक जाता है जब आपको स्टैक ट्रेस या कचरा इकट्ठा करने की आवश्यकता होती है। सफ़ारी पॉइंट्स के बारे में यहाँ और पढ़ें। यह ग्राफ दर्शाता है कि 1 मिनट में एक सर्वर इन बिंदुओं पर कितने मिलीसेकंड पर खर्च करता है।

डेटशीट संचालन चार्ट

और यहां रैंडल द्वारा कमीशन किए गए अद्भुत "स्कार्फ" हैं, जिनकी रिपोर्ट डेटाबेस पर आप पहले पढ़ सकते हैं। ये "स्कार्फ" हमें डेटाबेस-संचालन का मूल्यांकन करने की अनुमति देते हैं और हम कितनी मात्रा में चल रहे हैं।

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

इसी उद्देश्य के लिए, Yourkit API का उपयोग करते हुए , हमने परीक्षण के अंत में स्वचालित रूप से मेमोरी डंप और लोड प्रोफ़ाइल को हटा दिया। अब उन्हें केवल मैनुअल मोड में विश्लेषण किया जाता है, लेकिन इस प्रक्रिया को भी स्वचालित करने की योजना है।

चेरी

परीक्षण के अंत में, तथाकथित त्रुटि विश्लेषक लॉन्च किया जाता है। हम सभी त्रुटियों को लेते हैं - और उनमें से 100 गीगाबाइट तक कभी-कभी रात भर चलते हैं - और उन्हें अलमारियों पर रख देते हैं। हम तुलना करते हैं कि कौन सी त्रुटियां सबसे अधिक बार दोहराई जाती हैं और जो दुर्लभ हैं, और उन्हें समूहों में तोड़ देते हैं। प्रकार के अनुसार - त्रुटि, चेतावनी या सूचनात्मक संदेश - और पता करें कि क्या यह एक सामग्री त्रुटि है। हम QA सामग्री विशेषज्ञों को सामग्री त्रुटियां देते हैं, और हम सर्वर कोड में त्रुटियों की स्वयं जांच करते हैं।

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

भविष्य में, हम इस प्रणाली को विकसित करने की योजना बनाते हैं ताकि JIRA में कार्यों के साथ त्रुटियों को संबद्ध करना और एक संशोधन ढूंढना संभव हो जिसमें पहली बार त्रुटि देखी गई थी।

समस्याओं

लोड नाइट परीक्षणों में बहुत महंगी पुनरावृत्तियां होती हैं। प्रत्येक परीक्षण की लागत एक दिन है। बेशक, हम हर रात परीक्षण पास बनाने के लिए हर संभव प्रयास करते हैं, लेकिन वास्तव में यह सफलतापूर्वक कम बार गुजरता है, और पुनरावृत्तियां और भी महंगी हो जाती हैं। बुनियादी ढांचे के किसी भी नोड में कोई भी टूटने से परीक्षण बाधित हो सकता है।

निष्कर्ष

सभी प्रकार के आंकड़ों का उपयोग करके नियमित व्यायाम परीक्षण स्वस्थ नींद डेवलपर्स के लिए सबसे अच्छा उपकरण है। अब मैं कल्पना नहीं कर सकता कि आप इस तरह के परीक्षण के बिना कैसे रह सकते हैं, क्योंकि उसके लिए धन्यवाद, हर सुबह मैं देखता हूं कि हमारे पास ~~पूर्ण "आपातकालीन"~~ कहां हो सकता है। यह हमें सही दिशा में आगे बढ़ने में मदद करता है। आपका ध्यान के लिए धन्यवाद!

अन्य सामग्रियों को स्काईफोर डेवलपर्स वेबसाइट पर और हमारे Vkontakte समुदाय में देखा जा सकता है ।

रिपोर्ट बनाने और संपूर्ण स्काईफ़ोर सर्वर टीम को लेख लिखने में मदद के लिए धन्यवाद।

स्काईफोर, या बॉट्स में लोड परीक्षण - सर्वर ऑर्डर। भाग २