SRE: የአፈጻጸም ትንተና. በ Go ውስጥ ቀላል የድር አገልጋይን በመጠቀም የማዋቀር ዘዴ

የአፈጻጸም ትንተና እና ማስተካከያ ለደንበኞች የአፈጻጸም ተገዢነትን ለማረጋገጥ ኃይለኛ መሳሪያ ነው።

የአፈጻጸም ትንተና ለሙከራ ማስተካከያ ሳይንሳዊ አቀራረብን በመተግበር በፕሮግራሙ ውስጥ ያሉ ማነቆዎችን ለመፈተሽ ሊያገለግል ይችላል። ይህ ጽሑፍ የ Go webserverን እንደ ምሳሌ በመጠቀም የአፈጻጸም ትንተና እና ማስተካከያ አጠቃላይ አቀራረብን ይገልፃል።

ሂድ በተለይ እዚህ ጥሩ ነው ምክንያቱም የመገለጫ መሳሪያዎች አሉት pprof በመደበኛ ቤተ-መጽሐፍት ውስጥ.

ስልቱ

ለመዋቅር ትንተናችን ማጠቃለያ ዝርዝር እንፍጠር። በእውቀት ወይም በግምታዊ ስራ ላይ በመመስረት ለውጦችን ከማድረግ ይልቅ ውሳኔዎችን ለማድረግ አንዳንድ መረጃዎችን ለመጠቀም እንሞክራለን። ይህንን ለማድረግ ይህንን እናደርጋለን-

• የማመቻቸት ድንበሮችን እንወስናለን (መስፈርቶች);
• ለስርዓቱ የግብይት ጭነት እናሰላለን;
• ፈተናውን እናከናውናለን (ውሂብ ይፍጠሩ);
• እናስተውላለን;
• እኛ እንመረምራለን - ሁሉም መስፈርቶች ተሟልተዋል?
• በሳይንሳዊ መንገድ አዘጋጅተናል, መላምት እንሰራለን;
• ይህንን መላምት ለመፈተሽ ሙከራ እናደርጋለን።

ቀላል የኤችቲቲፒ አገልጋይ አርክቴክቸር

ለዚህ ጽሑፍ በጎላንግ ውስጥ ትንሽ የኤችቲቲፒ አገልጋይ እንጠቀማለን። ከዚህ ጽሑፍ ሁሉም ኮድ ሊገኝ ይችላል እዚህ.

እየተተነተነ ያለው መተግበሪያ ለእያንዳንዱ ጥያቄ Postgresql የሚመርጥ የኤችቲቲፒ አገልጋይ ነው። በተጨማሪም፣ የመተግበሪያ እና የስርዓት መለኪያዎችን ለመሰብሰብ እና ለማሳየት ፕሮሜቴየስ፣ node_exporter እና Grafana አሉ።

ለማቃለል፣ ለአግድም ልኬት (እና ስሌቶችን ለማቃለል) እያንዳንዱ አገልግሎት እና የውሂብ ጎታ በአንድ ላይ እንደሚሰማሩ እንመለከታለን፡-

ግቦችን መግለጽ

በዚህ ደረጃ, ግቡን እንወስናለን. ምን ለመተንተን እየሞከርን ነው? ጊዜው የሚያበቃበትን ጊዜ እንዴት እናውቃለን? በዚህ ጽሑፍ ውስጥ ደንበኞች እንዳሉን እና አገልግሎታችን በሰከንድ 10 ጥያቄዎችን እንደሚያስተናግድ እንገምታለን።

В Google SRE መጽሐፍ የመምረጫ እና ሞዴል ዘዴዎች በዝርዝር ተብራርተዋል. ተመሳሳይ ነገር እናድርግ እና ሞዴሎችን እንገንባ፡-

• መዘግየት፡ 99% ጥያቄዎች ከ60ms ባነሰ ጊዜ ውስጥ መሞላት አለባቸው።
• ዋጋ፡ አገልግሎቱ ምክንያታዊ ሊሆን ይችላል ብለን የምናስበውን አነስተኛውን የገንዘብ መጠን መጠቀም አለበት። ይህንን ለማድረግ የፍጆታ መጠንን ከፍ እናደርጋለን;
• የአቅም ማቀድ፡ የመተግበሪያውን ምን ያህል ሁኔታዎች ማስኬድ እንደሚያስፈልግ፣ አጠቃላይ የማስኬጃ ተግባራትን ጨምሮ፣ እና የመጀመሪያ ጭነት እና አቅርቦት መስፈርቶችን ለማሟላት ምን ያህል አጋጣሚዎች እንደሚያስፈልግ መረዳት እና መመዝገብ ያስፈልገዋል። ድግግሞሽ n+1.

መዘግየት ከመተንተን በተጨማሪ ማመቻቸትን ሊፈልግ ይችላል፣ነገር ግን የውጤት መጠን መተንተን አለበት። የSRE SLO ሂደትን ሲጠቀሙ፣ የመዘግየት ጥያቄ የሚመጣው ከደንበኛው ወይም ከንግድ፣ በምርቱ ባለቤት ነው። እና አገልግሎታችን ይህንን ግዴታ ከመጀመሪያው ጀምሮ ያለምንም ቅንጅቶች ይሟላል!

የሙከራ አካባቢን ማዘጋጀት

በሙከራ አካባቢ በመታገዝ በስርዓታችን ላይ የሚለካ ጭነት መጫን እንችላለን። ለመተንተን, በድር አገልግሎት አፈጻጸም ላይ ያለው መረጃ ይፈጠራል.

የግብይት ጭነት

ይህ አካባቢ ይጠቀማል Etaጋታ። እስኪቆም ድረስ ብጁ የኤችቲቲፒ ጥያቄ መጠን ለመፍጠር፡-

$ 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

ምልከታ

የግብይት ጭነት በሂደት ላይ ይውላል። ከአፕሊኬሽን (የጥያቄዎች ብዛት፣ ምላሽ መዘግየት) እና ኦፕሬቲንግ ሲስተም (ሜሞሪ፣ ሲፒዩ፣ አይኦፒኤስ) መለኪያዎች በተጨማሪ አፕሊኬሽኑ ችግሮች እንዳሉበት እና የሲፒዩ ጊዜ እንዴት ጥቅም ላይ እንደሚውል ለመረዳት ይሰራል።

መገለጫ ማድረግ

ፕሮፋይሊንግ አፕሊኬሽኑ ሲሰራ ሲፒዩ ጊዜ የት እንደሚሄድ ለማየት የሚያስችል የመለኪያ አይነት ነው። የአቀነባባሪው ጊዜ የት እና ምን ያህል እንደሚጠፋ በትክክል እንዲወስኑ ይፈቅድልዎታል-

ይህ መረጃ በሚባክን የሲፒዩ ጊዜ እና እየተሰራ ስላለው አላስፈላጊ ስራ ግንዛቤን ለማግኘት በመተንተን ወቅት መጠቀም ይቻላል። Go (pprof) መደበኛ የመሳሪያዎችን ስብስብ በመጠቀም መገለጫዎችን ማመንጨት እና እንደ የነበልባል ግራፍ አድርጎ ሊያያቸው ይችላል። ስለ አጠቃቀማቸው እና ስለ ማዋቀር መመሪያው በኋላ በጽሁፉ ውስጥ እናገራለሁ.

አፈፃፀም ፣ ምልከታ ፣ ትንተና።

አንድ ሙከራ እናድርግ። በአፈፃፀሙ እስክንረካ ድረስ እንፈፅማለን፣ እናስተውላለን። የመጀመሪያዎቹን ምልከታዎች ውጤት ለማግኘት እሱን ለመተግበር በዘፈቀደ ዝቅተኛ ጭነት ዋጋን እንመርጥ። በእያንዳንዱ ቀጣይ ደረጃ ላይ ጭነቱን በተወሰነ ልዩነት እንጨምራለን. እያንዳንዱ የጭነት ሙከራ ሂደት የሚከናወነው በጥያቄዎች ብዛት ነው፡- make load-test LOAD_TEST_RATE=X.

በሰከንድ 50 ጥያቄዎች

ለላይ ሁለት ግራፎች ትኩረት ይስጡ. ከላይ በግራ በኩል የእኛ መተግበሪያ በሰከንድ 50 ጥያቄዎችን እንደሚያስኬድ (እንደሚያስበው) እና ከላይ በቀኝ በኩል የእያንዳንዱን ጥያቄ ቆይታ ያሳያል። ሁለቱም መለኪያዎች በእኛ የአፈጻጸም ወሰኖች ውስጥ መሆናችንን ወይም አለመሆናችንን እንድንመለከት እና እንድንመረምር ይረዱናል። በግራፉ ላይ ቀይ መስመር HTTP የጥያቄ መዘግየት SLO 60ms ላይ ያሳያል። መስመሩ ከከፍተኛው የምላሽ ጊዜያችን በታች መሆናችንን ያሳያል።

የወጪውን ጎን እንመልከት፡-

10000 ጥያቄዎች በሰከንድ / 50 ጥያቄዎች በአንድ አገልጋይ = 200 አገልጋዮች + 1

አሁንም ይህንን አሃዝ ማሻሻል እንችላለን።

በሰከንድ 500 ጥያቄዎች

ጭነቱ በሰከንድ 500 ጥያቄዎች ሲደርስ የበለጠ አስደሳች ነገሮች መከሰት ይጀምራሉ፡-

በድጋሚ, በላይኛው ግራ ግራፍ ላይ አፕሊኬሽኑ መደበኛ ጭነት እየመዘገበ መሆኑን ማየት ይችላሉ. ጉዳዩ ይህ ካልሆነ, አፕሊኬሽኑ በሚሰራበት አገልጋይ ላይ ችግር አለ. የምላሽ መዘግየት ግራፍ ከላይ በቀኝ በኩል ይገኛል፣ ይህም በሰከንድ 500 ጥያቄዎች ከ25-40ms ምላሽ እንዲዘገይ አድርጓል። 99ኛው ፐርሰንታይል ከላይ ከተመረጠው የ60ሚሴ SLO ጋር በጥሩ ሁኔታ ይስማማል።

ከዋጋ አንፃር፡-

10000 ጥያቄዎች በሰከንድ / 500 ጥያቄዎች በአንድ አገልጋይ = 20 አገልጋዮች + 1

ሁሉም ነገር አሁንም ሊሻሻል ይችላል.

በሰከንድ 1000 ጥያቄዎች

ታላቅ ጅምር! አፕሊኬሽኑ በሰከንድ 1000 ጥያቄዎችን እንዳስተናገደ ያሳያል ነገርግን የቆይታ ጊዜ ገደብ በSLO ተጥሷል። ይህ በላይኛው ቀኝ ግራፍ ላይ ባለው መስመር p99 ላይ ይታያል። ምንም እንኳን የ p100 መስመር በጣም ከፍ ያለ ቢሆንም, ትክክለኛው መዘግየቶች ከከፍተኛው 60ms ከፍ ያለ ነው. አፕሊኬሽኑ በትክክል የሚሰራውን ለማወቅ ወደ ፕሮፋይሊንግ እንዝለቅ።

መገለጫ ማድረግ

ለመገለጫ, ጭነቱን በሰከንድ 1000 ጥያቄዎችን እናዘጋጃለን, ከዚያም እንጠቀማለን pprof አፕሊኬሽኑ የሲፒዩ ጊዜ የት እንደሚያጠፋ ለማወቅ መረጃን ለመያዝ። ይህ የኤችቲቲፒ መጨረሻ ነጥብን በማንቃት ሊከናወን ይችላል። 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

ግራፉ አፕሊኬሽኑ የሲፒዩ ጊዜ የት እና ምን ያህል እንደሚያጠፋ ያሳያል። ከ መግለጫው ብሬንዳን ግሬግ:

የ X ዘንግ የቁልል ፕሮፋይል ህዝብ ነው፣ በፊደል የተደረደረ (ይህ ጊዜ አይደለም)፣ Y ዘንግ የቁልል ጥልቀት ያሳያል፣ ከዜሮ [ከላይ] ይቆጥራል። እያንዳንዱ አራት ማእዘን የተቆለለ ፍሬም ነው። ሰፊው ፍሬም, ብዙ ጊዜ በተደራረቡ ውስጥ ይገኛል. ከላይ ያለው በሲፒዩ ላይ ይሰራል፣ እና ከታች ያለው የልጁ አካላት ናቸው። ቀለማቱ ብዙውን ጊዜ ምንም ማለት አይደለም ነገር ግን ፍሬሞችን ለመለየት በቀላሉ በዘፈቀደ የተመረጡ ናቸው።

ትንተና - መላምት

ለማስተካከል፣ የሚባክን ሲፒዩ ጊዜ ለማግኘት በመሞከር ላይ እናተኩራለን። ትልቁን ከንቱ የወጪ ምንጮችን እንፈልጋለን እና እናስወግዳቸዋለን። ጥሩ፣ ፕሮፋይሊንግ በትክክል አፕሊኬሽኑ ፕሮሰሰር ጊዜውን የት እንደሚያሳልፍ ስለሚያሳይ ብዙ ጊዜ ሊያደርጉት ይችላሉ፣ እና የመተግበሪያውን ምንጭ ኮድ መቀየር፣ ፈተናዎችን እንደገና ማካሄድ እና አፈፃፀሙ ወደ ኢላማው ሲቃረብ ማየት ያስፈልግዎታል።

የብሬንዳን ግሬግ ምክሮችን በመከተል ሰንጠረዡን ከላይ እስከ ታች እናነባለን። እያንዳንዱ መስመር ቁልል ፍሬም (የተግባር ጥሪ) ያሳያል። የመጀመሪያው መስመር የፕሮግራሙ መግቢያ ነጥብ ነው, የሌሎች ጥሪዎች ሁሉ ወላጅ (በሌላ አነጋገር, ሁሉም ሌሎች ጥሪዎች በእጃቸው ላይ ይኖራቸዋል). የሚቀጥለው መስመር አስቀድሞ የተለየ ነው፡-

ጠቋሚውን በግራፉ ላይ ባለው ተግባር ስም ላይ ቢያንዣብቡ፣ በማረም ጊዜ ቁልል ላይ የነበረው ጠቅላላ ጊዜ ይታያል። የ HTTPServe ተግባር 65% ጊዜ ነበር፣ ሌሎች የሩጫ ጊዜ ተግባራት runtime.mcall, mstart и gc, የቀረውን ጊዜ ወሰደ. አስደሳች እውነታ፡ ከጠቅላላው ጊዜ ውስጥ 5% የሚሆነው በዲ ኤን ኤስ መጠይቆች ላይ ይውላል፡-

ፕሮግራሙ የሚፈልጋቸው አድራሻዎች የ Postgresql ናቸው። ላይ ጠቅ ያድርጉ FindByAge:

የሚገርመው ነገር መርሃግብሩ እንደሚያሳየው በመርህ ደረጃ መዘግየትን የሚጨምሩ ሶስት ዋና ዋና ምንጮች አሉ-ግንኙነቶችን መክፈት እና መዝጋት ፣ መረጃን መጠየቅ እና ከመረጃ ቋቱ ጋር መገናኘት። ግራፉ እንደሚያሳየው የዲ ኤን ኤስ ጥያቄዎች፣ የመክፈቻ እና የመዝጋት ግንኙነቶች ከጠቅላላው የማስፈጸሚያ ጊዜ 13% ያህል ይወስዳሉ።

መላምት፡- ፑልኪንግን በመጠቀም ግንኙነቶችን እንደገና መጠቀም የአንድ ነጠላ HTTP ጥያቄ ጊዜን መቀነስ አለበት፣ ይህም ከፍተኛ ፍሰት እና ዝቅተኛ መዘግየት እንዲኖር ያስችላል።.

መተግበሪያውን ማዋቀር - ሙከራ

የምንጭ ኮዱን እናዘምነዋለን፣ ለእያንዳንዱ ጥያቄ ከ Postgresql ጋር ያለውን ግንኙነት ለማስወገድ እንሞክራለን። የመጀመሪያው አማራጭ መጠቀም ነው የግንኙነት ገንዳ በመተግበሪያው ደረጃ. በዚህ ሙከራ ውስጥ እኛ እናዋቅረው ለጉዞ sql ሾፌርን በመጠቀም የግንኙነት ገንዳ ማድረግ

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

if err != nil {
   return nil, err
}

አፈፃፀም ፣ ምልከታ ፣ ትንተና

ሙከራውን በሴኮንድ 1000 ጥያቄዎች እንደገና ከጀመረ በኋላ፣ የp99 መዘግየት ደረጃዎች በ SLO 60ms ወደ መደበኛ መመለሳቸው ግልፅ ነው!

ዋጋው ስንት ነው?

10000 ጥያቄዎች በሰከንድ / 1000 ጥያቄዎች በአንድ አገልጋይ = 10 አገልጋዮች + 1

የበለጠ እናድርገው!

በሰከንድ 2000 ጥያቄዎች

ጭነቱን በእጥፍ ማሳደግ ተመሳሳይ ነገር ያሳያል ፣ የላይኛው ግራ ግራፍ አፕሊኬሽኑ በሰከንድ 2000 ጥያቄዎችን ማስተናገድ እንደቻለ ያሳያል ፣ p100 ከ 60ms በታች ነው ፣ p99 SLO ን ያረካል።

ከዋጋ አንፃር፡-

10000 ጥያቄዎች በሰከንድ / 2000 ጥያቄዎች በአንድ አገልጋይ = 5 አገልጋዮች + 1

በሰከንድ 3000 ጥያቄዎች

እዚህ አፕሊኬሽኑ 3000 ጥያቄዎችን በp99 ከ60ms ባነሰ መዘግየት ማስተናገድ ይችላል። 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 ከ 60 ሚሴ በታች ነው ከ p100 ያነሰ!

የነበልባል ግራፉን መፈተሽ ግንኙነቱ የማይታወቅ መሆኑን ያሳያል! የበለጠ በዝርዝር እንፈትሽ pg(*conn).query - ግንኙነቱ እዚህ መፈጠሩንም አናስተውልም።

መደምደሚያ

የአፈጻጸም ትንተና የደንበኞች የሚጠበቁ እና ተግባራዊ ያልሆኑ መስፈርቶች እየተሟሉ መሆናቸውን ለመረዳት ወሳኝ ነው። ምልከታዎችን ከደንበኞች ከሚጠበቀው ጋር በማነፃፀር ትንተና ተቀባይነት ያለውን እና ያልሆነውን ለመወሰን ይረዳል. Go ትንታኔን ቀላል እና ተደራሽ የሚያደርግ በመደበኛ ቤተ-መጽሐፍት ውስጥ የተገነቡ ኃይለኛ መሳሪያዎችን ያቀርባል።

ምንጭ: hab.com