SRE: प्रदर्शन विश्लेषण। Go मा साधारण वेब सर्भर प्रयोग गरेर कन्फिगरेसन विधि

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

ट्युनिङ प्रयोगहरू परीक्षण गर्न वैज्ञानिक दृष्टिकोण लागू गरेर कार्यक्रममा अवरोधहरू जाँच गर्न प्रदर्शन विश्लेषण प्रयोग गर्न सकिन्छ। यस लेखले उदाहरणको रूपमा गो वेबसर्भर प्रयोग गरेर प्रदर्शन विश्लेषण र ट्युनिङको लागि सामान्य दृष्टिकोण परिभाषित गर्दछ।

गो यहाँ विशेष गरी राम्रो छ किनभने यसमा प्रोफाइलिङ उपकरणहरू छन् pprof मानक पुस्तकालयमा।

रणनीति

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

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

सरल HTTP सर्भर वास्तुकला

यस लेखको लागि हामी Golang मा सानो HTTP सर्भर प्रयोग गर्नेछौं। यस लेखबाट सबै कोड फेला पार्न सकिन्छ यहाँ.

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

सरलीकरण गर्न, हामी तेर्सो मापन (र गणना सरलीकरण) को लागि प्रत्येक सेवा र डाटाबेस सँगै तैनात गरिएको छ भनेर विचार गर्छौं:

लक्ष्यहरू परिभाषित गर्दै

यस चरणमा, हामी लक्ष्यमा निर्णय गर्छौं। हामीले के विश्लेषण गर्न खोजेका छौं? हामीले कसरी थाहा पाउने जब यो समाप्त हुने समय हो? यस लेखमा, हामी कल्पना गर्नेछौं कि हामीसँग ग्राहकहरू छन् र हाम्रो सेवाले प्रति सेकेन्ड १०,००० अनुरोधहरू प्रशोधन गर्नेछ।

В 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 को प्रतिक्रिया ढिलाइ भएको देखाउँदै। 99 औं प्रतिशत अझै पनि माथि छानिएको 60ms SLO मा राम्रोसँग फिट हुन्छ।

लागतको हिसाबले:

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

सबै अझै सुधार गर्न सकिन्छ।

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

उत्कृष्ट प्रक्षेपण! अनुप्रयोगले देखाउँछ कि यसले प्रति सेकेन्ड 1000 अनुरोधहरू प्रशोधन गर्यो, तर विलम्बता सीमा SLO द्वारा उल्लङ्घन गरिएको थियो। यसलाई शीर्ष दायाँ ग्राफमा लाइन p99 मा देख्न सकिन्छ। p100 लाइन धेरै उच्च छ भन्ने तथ्यको बावजुद, वास्तविक ढिलाइहरू अधिकतम 60ms भन्दा बढी छन्। एप्लिकेसनले वास्तवमा के गर्छ भनेर पत्ता लगाउन प्रोफाइलिङमा डुबौं।

प्रोफाइलिङ

प्रोफाइलिङको लागि, हामीले लोडलाई प्रति सेकेन्ड १००० अनुरोधहरूमा सेट गर्छौं, त्यसपछि प्रयोग गर्नुहोस् 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 अनुरोधहरूमा अनुप्रयोग डिबग गर्ने परिणामहरू सङ्कलन र प्रदर्शन गर्छौं:

अझै पनि ६% समय जडान स्थापनामा खर्च हुन्छ। पूल सेटअपले कार्यसम्पादन सुधार गरेको छ, तर तपाईले अझै पनि देख्न सक्नुहुन्छ कि अनुप्रयोगले डाटाबेसमा नयाँ जडानहरू सिर्जना गर्न काम जारी राखेको छ।

परिकल्पना: जडानहरू, पूलको उपस्थितिको बावजुद, अझै पनि छोडिएको छ र सफा गरिएको छ, त्यसैले अनुप्रयोगले तिनीहरूलाई रिसेट गर्न आवश्यक छ। पोखरी आकारमा पेन्डिङ जडानहरूको संख्या सेट गर्नाले अनुप्रयोगले जडान सिर्जना गर्न खर्च गरेको समयलाई कम गरेर विलम्बतामा मद्दत गर्नुपर्छ।.

अनुप्रयोग सेट अप गर्दै - प्रयोग

स्थापना गर्ने प्रयास गर्दै MaxIdleCons पूल साइज बराबर (यो पनि वर्णन गरिएको यहाँ):

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