SRE: कामगिरी विश्लेषण. Go मधील साधा वेब सर्व्हर वापरून सेटअप पद्धत

कार्यप्रदर्शन विश्लेषण आणि ट्यूनिंग हे क्लायंटसाठी कार्यप्रदर्शन अनुपालन सत्यापित करण्यासाठी एक शक्तिशाली साधन आहे.

ट्यूनिंग प्रयोगांच्या चाचणीसाठी वैज्ञानिक दृष्टीकोन लागू करून प्रोग्राममधील अडथळे तपासण्यासाठी कार्यप्रदर्शन विश्लेषणाचा वापर केला जाऊ शकतो. हा लेख उदाहरण म्हणून गो वेबसर्व्हर वापरून कार्यप्रदर्शन विश्लेषण आणि ट्यूनिंगसाठी सामान्य दृष्टीकोन परिभाषित करतो.

गो येथे विशेषतः चांगले आहे कारण त्यात प्रोफाइलिंग साधने आहेत pprof मानक ग्रंथालयात.

धोरण

चला आपल्या संरचनात्मक विश्लेषणासाठी सारांश सूची तयार करूया. अंतर्ज्ञान किंवा अंदाजावर आधारित बदल करण्याऐवजी आम्ही निर्णय घेण्यासाठी काही डेटा वापरण्याचा प्रयत्न करू. हे करण्यासाठी आम्ही हे करू:

• आम्ही ऑप्टिमायझेशन सीमा (आवश्यकता) निर्धारित करतो;
• आम्ही सिस्टमसाठी व्यवहार लोडची गणना करतो;
• आम्ही चाचणी करतो (डेटा तयार करा);
• आम्ही निरीक्षण करतो;
• आम्ही विश्लेषण करतो - सर्व आवश्यकता पूर्ण झाल्या आहेत का?
• आम्ही ते शास्त्रोक्त पद्धतीने मांडतो, गृहीतक तयार करतो;
• या गृहितकाची चाचणी घेण्यासाठी आम्ही एक प्रयोग करतो.

साधे HTTP सर्व्हर आर्किटेक्चर

या लेखासाठी आम्ही गोलंगमध्ये एक छोटा HTTP सर्व्हर वापरू. या लेखातील सर्व कोड आढळू शकतात येथे.

विश्‍लेषित केलेला अनुप्रयोग हा HTTP सर्व्हर आहे जो प्रत्येक विनंतीसाठी Postgresql पोल करतो. याव्यतिरिक्त, अनुप्रयोग आणि सिस्टम मेट्रिक्स एकत्रित आणि प्रदर्शित करण्यासाठी प्रोमिथियस, नोड_एक्सपोर्टर आणि ग्राफाना आहे.

सुलभ करण्यासाठी, आम्ही विचार करतो की क्षैतिज स्केलिंगसाठी (आणि गणना सुलभ करण्यासाठी) प्रत्येक सेवा आणि डेटाबेस एकत्र तैनात केले आहेत:

ध्येय निश्चित करणे

या टप्प्यावर, आम्ही ध्येय निश्चित करतो. आम्ही काय विश्लेषण करण्याचा प्रयत्न करीत आहोत? ते संपण्याची वेळ आली आहे हे आम्हाला कसे कळेल? या लेखात, आम्ही कल्पना करू की आमच्याकडे क्लायंट आहेत आणि आमची सेवा प्रति सेकंद 10 विनंत्यांवर प्रक्रिया करेल.

В Google SRE बुक निवड आणि मॉडेलिंगच्या पद्धतींवर तपशीलवार चर्चा केली आहे. चला तेच करू आणि मॉडेल बनवू:

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

विलंबासाठी विश्लेषणाव्यतिरिक्त ऑप्टिमायझेशन आवश्यक असू शकते, परंतु थ्रूपुटचे स्पष्टपणे विश्लेषण करणे आवश्यक आहे. SRE SLO प्रक्रिया वापरताना, विलंब विनंती ग्राहक किंवा व्यवसायाकडून येते, ज्याचे प्रतिनिधित्व उत्पादन मालक करतात. आणि आमची सेवा कोणत्याही सेटिंग्जशिवाय हे दायित्व अगदी सुरुवातीपासून पूर्ण करेल!

चाचणी वातावरण सेट करणे

चाचणी वातावरणाच्या मदतीने, आम्ही आमच्या सिस्टमवर मोजलेले लोड ठेवण्यास सक्षम होऊ. विश्लेषणासाठी, वेब सेवेच्या कार्यप्रदर्शनावरील डेटा व्युत्पन्न केला जाईल.

व्यवहार लोड

हे वातावरण वापरते भाजीपाला थांबेपर्यंत सानुकूल 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

निरीक्षण

रनटाइमच्या वेळी व्यवहाराचा भार लागू केला जाईल. अॅप्लिकेशन (विनंत्यांची संख्या, प्रतिसाद लेटन्सी) आणि ऑपरेटिंग सिस्टम (मेमरी, CPU, IOPS) मेट्रिक्स व्यतिरिक्त, अॅप्लिकेशन प्रोफाइलिंगमध्ये समस्या कुठे आहेत आणि CPU वेळ कसा वापरला जात आहे हे समजून घेण्यासाठी चालवले जाईल.

प्रोफाइलिंग

प्रोफाइलिंग हा एक प्रकारचा मापन आहे जो तुम्हाला अनुप्रयोग चालू असताना CPU वेळ कुठे जात आहे हे पाहण्याची परवानगी देतो. हे तुम्हाला प्रोसेसरचा वेळ नेमका कुठे आणि किती घालवायचा हे ठरवू देते:

या डेटाचा वापर विश्लेषणादरम्यान वाया जाणारा CPU वेळ आणि करण्यात येत असलेल्या अनावश्यक कामाची माहिती मिळवण्यासाठी केला जाऊ शकतो. Go (pprof) प्रोफाइल व्युत्पन्न करू शकते आणि साधनांचा मानक संच वापरून त्यांना फ्लेम आलेख म्हणून दृश्यमान करू शकते. मी लेखात नंतर त्यांच्या वापराबद्दल आणि सेटअप मार्गदर्शकाबद्दल बोलू.

अंमलबजावणी, निरीक्षण, विश्लेषण.

चला एक प्रयोग करूया. आम्ही कामगिरीवर समाधानी होईपर्यंत आम्ही कामगिरी करू, निरीक्षण करू आणि विश्लेषण करू. प्रथम निरीक्षणांचे परिणाम प्राप्त करण्यासाठी ते लागू करण्यासाठी आपण अनियंत्रितपणे कमी लोड मूल्य निवडू या. त्यानंतरच्या प्रत्येक पायरीवर आम्ही काही भिन्नतेसह निवडलेल्या विशिष्ट स्केलिंग घटकासह लोड वाढवू. प्रत्येक लोड चाचणी रन समायोजित केलेल्या विनंत्यांच्या संख्येसह केली जाते: make load-test LOAD_TEST_RATE=X.

प्रति सेकंद 50 विनंत्या

वरच्या दोन आलेखांकडे लक्ष द्या. शीर्ष डावीकडे दर्शविते की आमचा अनुप्रयोग प्रति सेकंद 50 विनंत्यांवर प्रक्रिया करतो (त्याचा विचार करतो) आणि शीर्ष उजवीकडे प्रत्येक विनंतीचा कालावधी दर्शवितो. दोन्ही पॅरामीटर्स आम्‍हाला पाहण्‍यात आणि विश्‍लेषण करण्‍यात मदत करतात की आम्‍ही आमच्‍या कार्यप्रदर्शन मर्यादेत आहोत की नाही. आलेखावर लाल रेषा HTTP विनंती विलंब 60ms वर SLO दाखवते. ओळ दर्शविते की आम्ही आमच्या कमाल प्रतिसाद वेळेच्या खाली आहोत.

चला खर्चाची बाजू पाहू:

प्रति सेकंद 10000 विनंत्या / 50 विनंत्या प्रति सर्व्हर = 200 सर्व्हर + 1

आम्ही अजूनही ही आकडेवारी सुधारू शकतो.

प्रति सेकंद 500 विनंत्या

जेव्हा लोड प्रति सेकंद 500 विनंत्यांपर्यंत पोहोचतो तेव्हा आणखी मनोरंजक गोष्टी घडू लागतात:

पुन्हा, वरच्या डाव्या आलेखामध्ये तुम्ही पाहू शकता की अनुप्रयोग सामान्य लोड रेकॉर्ड करत आहे. असे नसल्यास, ज्या सर्व्हरवर ऍप्लिकेशन चालू आहे त्यावर समस्या आहे. प्रतिसाद विलंब आलेख शीर्षस्थानी उजवीकडे स्थित आहे, हे दर्शविते की प्रति सेकंद 500 विनंत्यांमुळे प्रतिसादास 25-40ms विलंब झाला. वर निवडलेल्या 99ms SLO मध्ये 60 वा पर्सेंटाइल अजूनही छान बसतो.

खर्चाच्या बाबतीत:

प्रति सेकंद 10000 विनंत्या / 500 विनंत्या प्रति सर्व्हर = 20 सर्व्हर + 1

तरीही सर्व काही सुधारले जाऊ शकते.

प्रति सेकंद 1000 विनंत्या

उत्तम प्रक्षेपण! अनुप्रयोग दर्शवितो की त्याने प्रति सेकंद 1000 विनंत्यांवर प्रक्रिया केली, परंतु SLO द्वारे विलंब मर्यादेचे उल्लंघन केले गेले. हे वरच्या उजव्या आलेखामध्ये p99 ओळीत पाहिले जाऊ शकते. p100 ओळ खूप जास्त असूनही, वास्तविक विलंब कमाल 60ms पेक्षा जास्त आहे. अनुप्रयोग प्रत्यक्षात काय करतो हे शोधण्यासाठी प्रोफाइलिंगमध्ये जाऊ या.

प्रोफाइलिंग

प्रोफाइलिंगसाठी, आम्ही लोड प्रति सेकंद 1000 विनंत्यांवर सेट करतो, नंतर वापरा pprof अनुप्रयोग CPU वेळ कुठे घालवत आहे हे शोधण्यासाठी डेटा कॅप्चर करण्यासाठी. हे 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 वेळ कुठे आणि किती खर्च करतो हे आलेख दाखवतो. पासून वर्णन पासून ब्रेंडन ग्रेग:

X अक्ष ही स्टॅक प्रोफाइलची लोकसंख्या आहे, वर्णक्रमानुसार क्रमवारी लावलेली आहे (ही वेळ नाही), Y अक्ष स्टॅकची खोली दर्शवितो, [शीर्ष] वर शून्यापासून मोजतो. प्रत्येक आयत एक स्टॅक फ्रेम आहे. फ्रेम जितकी विस्तीर्ण असेल तितकीच ती स्टॅकमध्ये असते. वरती जे आहे ते CPU वर चालते आणि खाली जे आहे ते मूल घटक आहेत. रंगांचा सहसा काहीही अर्थ नसतो, परंतु फ्रेम वेगळे करण्यासाठी यादृच्छिकपणे निवडले जातात.

विश्लेषण - गृहीतक

ट्यूनिंगसाठी, आम्ही वाया गेलेला CPU वेळ शोधण्याचा प्रयत्न करण्यावर लक्ष केंद्रित करू. आम्ही निरुपयोगी खर्चाचे सर्वात मोठे स्त्रोत शोधू आणि ते काढून टाकू. बरं, प्रोफाइलिंगमुळे अनुप्रयोग त्याच्या प्रोसेसरचा वेळ नेमका कोठे घालवत आहे हे अगदी अचूकपणे प्रकट करते, आपल्याला ते अनेक वेळा करावे लागेल आणि आपल्याला अनुप्रयोग स्त्रोत कोड बदलण्याची देखील आवश्यकता असेल, चाचण्या पुन्हा चालवाव्या लागतील आणि कार्यप्रदर्शन लक्ष्यापर्यंत पोहोचेल हे पहावे लागेल.

ब्रेंडन ग्रेगच्या शिफारसींचे अनुसरण करून, आम्ही वरपासून खालपर्यंत चार्ट वाचू. प्रत्येक ओळ स्टॅक फ्रेम (फंक्शन कॉल) प्रदर्शित करते. पहिली ओळ म्हणजे प्रोग्राममधील एंट्री पॉइंट, इतर सर्व कॉलचे पालक (दुसऱ्या शब्दात, इतर सर्व कॉल्सच्या स्टॅकवर ते असतील). पुढील ओळ आधीच वेगळी आहे:

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

प्रोग्राम शोधत असलेले पत्ते Postgresql चे आहेत. वर क्लिक करा FindByAge:

मनोरंजकपणे, प्रोग्राम दर्शवितो की, तत्त्वतः, तीन मुख्य स्त्रोत आहेत जे विलंब जोडतात: कनेक्शन उघडणे आणि बंद करणे, डेटाची विनंती करणे आणि डेटाबेसशी कनेक्ट करणे. आलेख दर्शवितो की DNS विनंत्या, उघडणे आणि बंद करणे कनेक्शन एकूण अंमलबजावणी वेळेपैकी सुमारे 13% घेतात.

गृहीतक: पूलिंगचा वापर करून कनेक्शनचा पुनर्वापर केल्याने एकाच HTTP विनंतीचा वेळ कमी झाला पाहिजे, ज्यामुळे उच्च थ्रुपुट आणि कमी विलंब होऊ शकतो.

अनुप्रयोग सेट करणे - प्रयोग

आम्ही स्त्रोत कोड अद्यतनित करतो, प्रत्येक विनंतीसाठी Postgresql चे कनेक्शन काढण्याचा प्रयत्न करा. पहिला पर्याय वापरणे आहे कनेक्शन पूल अर्ज स्तरावर. या प्रयोगात आम्ही चला ते सेट करूया जाण्यासाठी sql ड्राइव्हर वापरून कनेक्शन पूलिंग:

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

if err != nil {
   return nil, err
}

अंमलबजावणी, निरीक्षण, विश्लेषण

प्रति सेकंद 1000 विनंत्यांसह चाचणी रीस्टार्ट केल्यानंतर, हे स्पष्ट आहे की p99 ची विलंब पातळी 60ms च्या SLO सह सामान्य झाली आहे!

किंमत किती आहे?

प्रति सेकंद 10000 विनंत्या / 1000 विनंत्या प्रति सर्व्हर = 10 सर्व्हर + 1

चला ते आणखी चांगले करूया!

प्रति सेकंद 2000 विनंत्या

लोड दुप्पट करणे समान गोष्ट दर्शविते, वरचा डावा आलेख दर्शवितो की अनुप्रयोग प्रति सेकंद 2000 विनंत्यांवर प्रक्रिया करतो, p100 60ms पेक्षा कमी आहे, p99 SLO चे समाधान करतो.

खर्चाच्या बाबतीत:

प्रति सेकंद 10000 विनंत्या / 2000 विनंत्या प्रति सर्व्हर = 5 सर्व्हर + 1

प्रति सेकंद 3000 विनंत्या

येथे अनुप्रयोग 3000ms पेक्षा कमी p99 लेटन्सीसह 60 विनंत्यांवर प्रक्रिया करू शकतो. SLO चे उल्लंघन केले जात नाही, आणि किंमत खालीलप्रमाणे स्वीकारली जाते:

प्रति सेकंद 10000 विनंत्या / प्रति सर्व्हर 3000 विनंत्या = 4 सर्व्हर + 1 (लेखकाने गोळाबेरीज केली आहे, अंदाजे अनुवादक)

विश्लेषणाची दुसरी फेरी करून पाहू.

विश्लेषण - गृहीतक

आम्ही प्रति सेकंद 3000 विनंत्यानुसार अनुप्रयोग डीबग करण्याचे परिणाम संकलित करतो आणि प्रदर्शित करतो:

अद्याप 6% वेळ कनेक्शन स्थापित करण्यासाठी खर्च केला जातो. पूल सेट केल्याने कार्यप्रदर्शन सुधारले आहे, परंतु तरीही आपण पाहू शकता की अनुप्रयोग डेटाबेसमध्ये नवीन कनेक्शन तयार करण्यासाठी कार्य करत आहे.

गृहीतक: पूल अस्तित्वात असूनही कनेक्शन अद्याप टाकले जातात आणि साफ केले जातात, म्हणून अनुप्रयोगास ते रीसेट करणे आवश्यक आहे. पूल आकारात प्रलंबित कनेक्शनची संख्या सेट केल्याने अनुप्रयोग कनेक्शन तयार करण्यासाठी घालवणारा वेळ कमी करून विलंब होण्यास मदत करेल.

अनुप्रयोग सेट करणे - प्रयोग

स्थापित करण्याचा प्रयत्न करत आहे MaxIdleConns पूल आकाराच्या समान (हे देखील वर्णन केले आहे येथे):

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 — येथे कनेक्शन स्थापित होत असल्याचे आमच्या लक्षात येत नाही.

निष्कर्ष

ग्राहकांच्या अपेक्षा आणि गैर-कार्यक्षम आवश्यकता पूर्ण केल्या जात आहेत हे समजून घेण्यासाठी कार्यप्रदर्शन विश्लेषण महत्त्वपूर्ण आहे. ग्राहकांच्या अपेक्षांसह निरीक्षणांची तुलना करून विश्लेषण काय स्वीकार्य आहे आणि काय नाही हे निर्धारित करण्यात मदत करू शकते. Go मानक लायब्ररीमध्ये तयार केलेली शक्तिशाली साधने प्रदान करते जे विश्लेषण सोपे आणि प्रवेशयोग्य बनवते.

स्त्रोत: www.habr.com