एसआरई: प्रदर्शन विश्लेषण। गो में एक साधारण वेब सर्वर का उपयोग करके कॉन्फ़िगरेशन विधि

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

ट्यूनिंग प्रयोगों के परीक्षण के लिए वैज्ञानिक दृष्टिकोण लागू करके किसी कार्यक्रम में बाधाओं की जांच करने के लिए प्रदर्शन विश्लेषण का उपयोग किया जा सकता है। यह आलेख एक उदाहरण के रूप में गो वेबसर्वर का उपयोग करके प्रदर्शन विश्लेषण और ट्यूनिंग के लिए एक सामान्य दृष्टिकोण को परिभाषित करता है।

गो यहां विशेष रूप से अच्छा है क्योंकि इसमें प्रोफाइलिंग टूल हैं pprof मानक पुस्तकालय में.

रणनीति

आइए अपने संरचनात्मक विश्लेषण के लिए एक सारांश सूची बनाएं। हम अंतर्ज्ञान या अनुमान के आधार पर परिवर्तन करने के बजाय निर्णय लेने के लिए कुछ डेटा का उपयोग करने का प्रयास करेंगे। ऐसा करने के लिए हम यह करेंगे:

• हम अनुकूलन सीमाएँ (आवश्यकताएँ) निर्धारित करते हैं;
• हम सिस्टम के लिए लेनदेन भार की गणना करते हैं;
• हम परीक्षण करते हैं (डेटा बनाते हैं);
• हम निरीक्षण करते हैं;
• हम विश्लेषण करते हैं - क्या सभी आवश्यकताएँ पूरी होती हैं?
• हम इसे वैज्ञानिक ढंग से स्थापित करते हैं, एक परिकल्पना बनाते हैं;
• हम इस परिकल्पना का परीक्षण करने के लिए एक प्रयोग करते हैं।

सरल HTTP सर्वर आर्किटेक्चर

इस लेख के लिए हम गोलांग में एक छोटे HTTP सर्वर का उपयोग करेंगे। इस आलेख से सभी कोड पाए जा सकते हैं यहां.

विश्लेषण किया जा रहा एप्लिकेशन एक HTTP सर्वर है जो प्रत्येक अनुरोध के लिए Postgresql का सर्वेक्षण करता है। इसके अतिरिक्त, एप्लिकेशन और सिस्टम मेट्रिक्स को इकट्ठा करने और प्रदर्शित करने के लिए प्रोमेथियस, नोड_एक्सपोर्टर और ग्राफाना है।

सरल बनाने के लिए, हम मानते हैं कि क्षैतिज स्केलिंग (और गणना को सरल बनाने) के लिए प्रत्येक सेवा और डेटाबेस को एक साथ तैनात किया जाता है:

लक्ष्य परिभाषित करना

इस चरण में, हम लक्ष्य तय करते हैं। हम क्या विश्लेषण करने का प्रयास कर रहे हैं? हमें कैसे पता चलेगा कि कब ख़त्म होने का समय आ गया है? इस लेख में, हम कल्पना करेंगे कि हमारे पास ग्राहक हैं और हमारी सेवा प्रति सेकंड 10 अनुरोधों को संसाधित करेगी।

В गूगल एसआरई बुक चयन और मॉडलिंग के तरीकों पर विस्तार से चर्चा की गई है। आइए ऐसा ही करें और मॉडल बनाएं:

• विलंबता: 99% अनुरोध 60 एमएस से कम समय में पूरे होने चाहिए;
• लागत: सेवा में न्यूनतम धनराशि खर्च होनी चाहिए जो हम उचित रूप से संभव समझते हैं। ऐसा करने के लिए, हम थ्रूपुट को अधिकतम करते हैं;
• क्षमता नियोजन: यह समझने और दस्तावेजीकरण करने की आवश्यकता है कि समग्र स्केलिंग कार्यक्षमता सहित एप्लिकेशन के कितने उदाहरणों को चलाने की आवश्यकता होगी, और प्रारंभिक लोड और प्रावधान आवश्यकताओं को पूरा करने के लिए कितने उदाहरणों की आवश्यकता होगी अतिरेक n+1.

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

एक परीक्षण वातावरण स्थापित करना

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

लेन-देन का भार

यह वातावरण उपयोग करता है उगना रुकने तक एक कस्टम HTTP अनुरोध दर बनाने के लिए:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

देख

लेनदेन संबंधी भार रनटाइम पर लागू किया जाएगा. एप्लिकेशन (अनुरोधों की संख्या, प्रतिक्रिया विलंबता) और ऑपरेटिंग सिस्टम (मेमोरी, सीपीयू, आईओपीएस) मेट्रिक्स के अलावा, एप्लिकेशन प्रोफाइलिंग को यह समझने के लिए चलाया जाएगा कि इसमें कहां समस्याएं हैं और सीपीयू समय की खपत कैसे हो रही है।

रूपरेखा

प्रोफाइलिंग एक प्रकार का माप है जो आपको यह देखने की अनुमति देता है कि जब कोई एप्लिकेशन चल रहा हो तो सीपीयू का समय कहां जा रहा है। यह आपको यह निर्धारित करने की अनुमति देता है कि प्रोसेसर का समय कहाँ और कितना खर्च हुआ है:

इस डेटा का उपयोग विश्लेषण के दौरान बर्बाद सीपीयू समय और किए जा रहे अनावश्यक कार्य के बारे में जानकारी प्राप्त करने के लिए किया जा सकता है। गो (पीप्रोफ़) टूल के एक मानक सेट का उपयोग करके प्रोफाइल तैयार कर सकता है और उन्हें फ्लेम ग्राफ़ के रूप में देख सकता है। मैं लेख में बाद में उनके उपयोग और सेटअप गाइड के बारे में बात करूंगा।

निष्पादन, अवलोकन, विश्लेषण।

आइए एक प्रयोग करें. हम तब तक प्रदर्शन, निरीक्षण और विश्लेषण करेंगे जब तक हम प्रदर्शन से संतुष्ट नहीं हो जाते। आइए हम पहले अवलोकनों के परिणाम प्राप्त करने के लिए इसे लागू करने के लिए एक मनमाने ढंग से कम लोड मान चुनें। प्रत्येक अगले चरण में हम कुछ बदलावों के साथ चुने गए एक निश्चित स्केलिंग कारक के साथ लोड बढ़ाएंगे। प्रत्येक लोड परीक्षण रन समायोजित अनुरोधों की संख्या के साथ किया जाता है: make load-test LOAD_TEST_RATE=X.

प्रति सेकंड 50 अनुरोध

शीर्ष दो ग्राफ़ पर ध्यान दें. शीर्ष बाईं ओर से पता चलता है कि हमारा एप्लिकेशन प्रति सेकंड 50 अनुरोधों को संसाधित करता है (ऐसा लगता है) और शीर्ष दाईं ओर प्रत्येक अनुरोध की अवधि को दर्शाता है। दोनों पैरामीटर हमें यह देखने और विश्लेषण करने में मदद करते हैं कि हम अपनी प्रदर्शन सीमाओं के भीतर हैं या नहीं। ग्राफ़ पर लाल रेखा HTTP अनुरोध विलंबता 60ms पर SLO दिखाता है। रेखा दर्शाती है कि हम अपने अधिकतम प्रतिक्रिया समय से काफी नीचे हैं।

आइए लागत पक्ष पर नजर डालें:

प्रति सेकंड 10000 अनुरोध / प्रति सर्वर 50 अनुरोध = 200 सर्वर + 1

हम अभी भी इस आंकड़े में सुधार कर सकते हैं.

प्रति सेकंड 500 अनुरोध

अधिक दिलचस्प चीजें तब घटित होने लगती हैं जब लोड 500 अनुरोध प्रति सेकंड तक पहुंच जाता है:

पुनः, शीर्ष बाएँ ग्राफ़ में आप देख सकते हैं कि एप्लिकेशन सामान्य लोड रिकॉर्ड कर रहा है। यदि ऐसा नहीं है, तो उस सर्वर पर कोई समस्या है जिस पर एप्लिकेशन चल रहा है। प्रतिक्रिया विलंबता ग्राफ़ शीर्ष दाईं ओर स्थित है, जो दर्शाता है कि प्रति सेकंड 500 अनुरोधों के परिणामस्वरूप प्रतिक्रिया में 25-40ms की देरी हुई। 99वाँ प्रतिशतक अभी भी ऊपर चुने गए 60ms SLO में अच्छी तरह फिट बैठता है।

लागत के संदर्भ में:

प्रति सेकंड 10000 अनुरोध / प्रति सर्वर 500 अनुरोध = 20 सर्वर + 1

सब कुछ अभी भी सुधारा जा सकता है.

प्रति सेकंड 1000 अनुरोध

शानदार लॉन्च! एप्लिकेशन दिखाता है कि उसने प्रति सेकंड 1000 अनुरोध संसाधित किए, लेकिन एसएलओ द्वारा विलंबता सीमा का उल्लंघन किया गया था। इसे शीर्ष दाएँ ग्राफ़ में पंक्ति p99 में देखा जा सकता है। इस तथ्य के बावजूद कि p100 लाइन बहुत अधिक है, वास्तविक विलंब अधिकतम 60ms से अधिक है। आइए यह जानने के लिए प्रोफाइलिंग में उतरें कि एप्लिकेशन वास्तव में क्या करता है।

रूपरेखा

प्रोफ़ाइलिंग के लिए, हम लोड को प्रति सेकंड 1000 अनुरोधों पर सेट करते हैं, फिर उपयोग करते हैं pprof यह पता लगाने के लिए डेटा कैप्चर करना कि एप्लिकेशन सीपीयू समय कहां खर्च कर रहा है। यह HTTP एंडपॉइंट को सक्रिय करके किया जा सकता है pprof, और फिर, लोड के तहत, कर्ल का उपयोग करके परिणाम सहेजें:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

परिणाम इस प्रकार प्रदर्शित किये जा सकते हैं:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

ग्राफ़ दिखाता है कि एप्लिकेशन CPU समय कहाँ और कितना खर्च करता है। से विवरण से ब्रेंडन ग्रेग:

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

विश्लेषण - परिकल्पना

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

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

यदि आप ग्राफ़ पर किसी फ़ंक्शन के नाम पर कर्सर घुमाते हैं, तो डिबगिंग के दौरान स्टैक पर बिताया गया कुल समय प्रदर्शित होगा। HTTPServe फ़ंक्शन 65% समय, अन्य रनटाइम फ़ंक्शंस में मौजूद था runtime.mcall, mstart и gc, बाकी समय ले लिया। मज़ेदार तथ्य: कुल समय का 5% DNS क्वेरीज़ पर खर्च होता है:

प्रोग्राम जिन पतों को खोजता है वे Postgresql के हैं। पर क्लिक करें FindByAge:

दिलचस्प बात यह है कि कार्यक्रम दिखाता है कि, सिद्धांत रूप में, तीन मुख्य स्रोत हैं जो देरी जोड़ते हैं: कनेक्शन खोलना और बंद करना, डेटा का अनुरोध करना और डेटाबेस से कनेक्ट करना। ग्राफ़ दिखाता है कि DNS अनुरोध, कनेक्शन खोलने और बंद करने में कुल निष्पादन समय का लगभग 13% समय लगता है।

हाइपोथीसिस: पूलिंग का उपयोग करके कनेक्शन का पुन: उपयोग करने से एकल HTTP अनुरोध का समय कम हो जाना चाहिए, जिससे उच्च थ्रूपुट और कम विलंबता की अनुमति मिलेगी.

एप्लिकेशन सेट करना - प्रयोग

हम स्रोत कोड को अपडेट करते हैं, प्रत्येक अनुरोध के लिए Postgresql से कनेक्शन हटाने का प्रयास करते हैं। पहला विकल्प उपयोग करना है कनेक्शन पूल आवेदन स्तर पर. इस प्रयोग में हम आइए इसे सेट करें जाने के लिए एसक्यूएल ड्राइवर का उपयोग करके कनेक्शन पूलिंग:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

निष्पादन, अवलोकन, विश्लेषण

प्रति सेकंड 1000 अनुरोधों के साथ परीक्षण को पुनः आरंभ करने के बाद, यह स्पष्ट है कि पी99 का विलंबता स्तर 60 एमएस के एसएलओ के साथ सामान्य पर वापस आ गया है!

लागत क्या है?

प्रति सेकंड 10000 अनुरोध / प्रति सर्वर 1000 अनुरोध = 10 सर्वर + 1

आइए इसे और भी बेहतर तरीके से करें!

प्रति सेकंड 2000 अनुरोध

लोड को दोगुना करना एक ही चीज़ दिखाता है, ऊपरी बाएँ ग्राफ़ से पता चलता है कि एप्लिकेशन प्रति सेकंड 2000 अनुरोधों को संसाधित करने का प्रबंधन करता है, p100 60ms से कम है, p99 SLO को संतुष्ट करता है।

लागत के संदर्भ में:

प्रति सेकंड 10000 अनुरोध / प्रति सर्वर 2000 अनुरोध = 5 सर्वर + 1

प्रति सेकंड 3000 अनुरोध

यहां एप्लिकेशन 3000ms से कम की p99 विलंबता के साथ 60 अनुरोधों को संसाधित कर सकता है। एसएलओ का उल्लंघन नहीं किया गया है, और लागत निम्नानुसार स्वीकार की जाती है:

10000 अनुरोध प्रति सेकंड / प्रति 3000 अनुरोध प्रति सर्वर = 4 सर्वर + 1 (लेखक ने पूरा किया है, लगभग। अनुवादक)

आइए विश्लेषण के एक और दौर का प्रयास करें।

विश्लेषण - परिकल्पना

हम प्रति सेकंड 3000 अनुरोधों पर एप्लिकेशन डिबगिंग के परिणाम एकत्र और प्रदर्शित करते हैं:

अभी भी 6% समय कनेक्शन स्थापित करने में खर्च होता है। पूल स्थापित करने से प्रदर्शन में सुधार हुआ है, लेकिन आप अभी भी देख सकते हैं कि एप्लिकेशन डेटाबेस में नए कनेक्शन बनाने पर काम करना जारी रखता है।

हाइपोथीसिस: पूल की मौजूदगी के बावजूद, कनेक्शन अभी भी हटा दिए जाते हैं और साफ किए जाते हैं, इसलिए एप्लिकेशन को उन्हें रीसेट करने की आवश्यकता होती है। लंबित कनेक्शनों की संख्या को पूल आकार पर सेट करने से एप्लिकेशन द्वारा कनेक्शन बनाने में लगने वाले समय को कम करके विलंबता में मदद मिलनी चाहिए.

एप्लिकेशन सेट करना - प्रयोग

स्थापित करने का प्रयास किया जा रहा है मैक्सआइडलकॉन्स पूल आकार के बराबर (यह भी वर्णित है)। यहां):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

निष्पादन, अवलोकन, विश्लेषण

प्रति सेकंड 3000 अनुरोध

p99 काफी कम p60 के साथ 100ms से कम है!

लौ ग्राफ़ की जाँच से पता चलता है कि कनेक्शन अब ध्यान देने योग्य नहीं है! आइए अधिक विस्तार से जांचें pg(*conn).query - हम यहां स्थापित किए जा रहे कनेक्शन पर भी ध्यान नहीं देते हैं।

निष्कर्ष

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

स्रोत: www.habr.com