SRE: Pagtuki sa Pagganap. Pamaagi sa pag-configure gamit ang usa ka yano nga web server sa Go

Ang pag-analisa ug pag-tune sa pasundayag usa ka kusgan nga himan alang sa pag-verify sa pagsunod sa pasundayag alang sa mga kliyente.

Ang pag-analisa sa performance mahimong magamit aron masusi ang mga bottleneck sa usa ka programa pinaagi sa paggamit ug siyentipikong pamaagi sa pagsulay sa mga eksperimento sa tuning. Kini nga artikulo naghubit sa usa ka kinatibuk-ang pamaagi sa pagtuki sa performance ug pag-tune, gamit ang Go webserver isip usa ka pananglitan.

Ang Go labi ka maayo dinhi tungod kay kini adunay mga himan sa pag-profile pprof sa standard library.

Ang Diskarte

Magbuhat ta ug summary list para sa atong structural analysis. Atong sulayan ang paggamit sa pipila ka mga datos sa paghimo og mga desisyon imbes nga maghimo og mga pagbag-o base sa intuition o guesswork. Sa pagbuhat niini atong buhaton kini:

• Gitino namo ang mga utlanan sa pag-optimize (mga kinahanglanon);
• Gikalkulo namo ang load sa transaksyon alang sa sistema;
• Gihimo namo ang pagsulay (paghimo og datos);
• Atong obserbahan;
• Atong analisahon - natuman ba ang tanan nga mga kinahanglanon?
• Gipahimutang namo kini sa siyentipikanhong paagi, naghimo ug hypothesis;
• Naghimo kami usa ka eksperimento aron sulayan kini nga hypothesis.

Yano nga HTTP Server Architecture

Alang sa kini nga artikulo mogamit kami usa ka gamay nga server sa HTTP sa Golang. Ang tanan nga code gikan sa kini nga artikulo makit-an dinhi.

Ang aplikasyon nga gi-analisa usa ka HTTP server nga nagboto sa Postgresql alang sa matag hangyo. Dugang pa, adunay Prometheus, node_exporter ug Grafana alang sa pagkolekta ug pagpakita sa mga sukatan sa aplikasyon ug sistema.

Aron pasimplehon, among gikonsiderar nga alang sa pinahigda nga pag-scale (ug pagpasimple sa mga kalkulasyon) ang matag serbisyo ug database gi-deploy nga magkauban:

Pagtino sa mga tumong

Niini nga lakang, magdesisyon kami sa tumong. Unsa ang atong gisulayan pag-analisar? Giunsa nato pagkahibalo kung panahon na sa pagtapos? Niini nga artikulo, mahanduraw namon nga kami adunay mga kliyente ug nga ang among serbisyo magproseso sa 10 nga mga hangyo matag segundo.

В Google SRE nga Libro Ang mga pamaagi sa pagpili ug pagmodelo gihisgutan sa detalye. Buhaton nato ang sama ug paghimo og mga modelo:

• Latency: 99% sa mga hangyo kinahanglang makompleto sa ubos sa 60ms;
• Gasto: Ang serbisyo kinahanglan nga mogamit sa labing gamay nga kantidad sa salapi nga gihunahuna namon nga posible. Aron mahimo kini, among gipadako ang throughput;
• Pagplano sa kapasidad: Nanginahanglan og pagsabot ug pagdokumento kung pila ka mga higayon sa aplikasyon ang kinahanglan nga ipadagan, lakip ang kinatibuk-ang pagpaandar sa pag-scale, ug pila ka mga higayon ang kinahanglan aron matubag ang mga kinahanglanon sa pagkarga ug paghatag. kalabisan n+1.

Ang latency mahimong magkinahanglan og optimization dugang sa pagtuki, apan ang throughput klaro nga kinahanglang analisahon. Kung gigamit ang proseso sa SRE SLO, ang hangyo sa paglangan gikan sa kustomer o negosyo, nga girepresentahan sa tag-iya sa produkto. Ug ang among serbisyo magtuman niini nga obligasyon gikan sa sinugdanan nga wala’y bisan unsang mga setting!

Pagpahimutang sa usa ka palibot sa pagsulay

Sa tabang sa usa ka palibot sa pagsulay, mahimo namon nga ibutang ang usa ka gisukod nga karga sa among sistema. Alang sa pag-analisar, ang datos sa pasundayag sa serbisyo sa web mabuhat.

Pagkarga sa transaksyon

Kini nga palibot naggamit Vegeta sa paghimo og custom HTTP request rate hangtod nga mohunong:

$ 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

Pagtan-aw

Ang transactional load i-apply sa runtime. Gawas pa sa mga sukatan sa aplikasyon (gidaghanon sa mga hangyo, mga latency sa pagtubag) ug operating system (memorya, CPU, IOPS), ang profiling sa aplikasyon ilunsad aron masabtan kung diin kini adunay mga problema, ingon man kung giunsa ang paggamit sa oras sa CPU.

Pag-profile

Ang pag-profile usa ka matang sa pagsukod nga nagtugot kanimo nga makita kung asa moadto ang oras sa CPU kung ang usa ka aplikasyon nagdagan. Gitugotan ka niini nga mahibal-an kung diin ug pila ang oras sa processor nga gigasto:

Kini nga datos mahimong magamit sa panahon sa pagtuki aron makakuha og panabut sa nausik nga oras sa CPU ug wala kinahanglana nga trabaho nga gihimo. Ang Go (pprof) makahimo og mga profile ug mahanduraw kini isip mga flame graph gamit ang standard set sa mga himan. Maghisgot ako bahin sa ilang paggamit ug giya sa pag-setup sa ulahi sa artikulo.

Pagpatuman, obserbasyon, pagtuki.

Maghimo kita og eksperimento. Magbuhat kami, mag-obserbar ug mag-analisar hangtod nga matagbaw kami sa pasundayag. Atong pilion ang usa ka arbitraryong ubos nga kantidad sa pagkarga aron magamit kini aron makuha ang mga resulta sa unang mga obserbasyon. Sa matag sunod-sunod nga lakang atong dugangan ang load sa usa ka piho nga scaling factor, gipili uban sa pipila ka mga kalainan. Ang matag load testing run gihimo uban ang gidaghanon sa mga hangyo nga gi-adjust: make load-test LOAD_TEST_RATE=X.

50 nga mga hangyo matag segundo

Hatagi'g pagtagad ang ibabaw nga duha ka mga graph. Ang ibabaw nga wala nagpakita nga ang among aplikasyon nagproseso sa 50 ka hangyo matag segundo (kini naghunahuna) ug ang ibabaw nga tuo nagpakita sa gidugayon sa matag hangyo. Ang duha ka mga parameter makatabang kanato sa pagtan-aw ug pag-analisar kung naa ba kita sa sulod sa atong mga limitasyon sa pasundayag o wala. Pula nga linya sa graph HTTP Request Latency nagpakita sa SLO sa 60ms. Gipakita sa linya nga ubos kaayo kami sa among labing taas nga oras sa pagtubag.

Atong tan-awon ang bahin sa gasto:

10000 ka hangyo kada segundo / 50 ka hangyo kada server = 200 ka server + 1

Mapauswag pa nato kini nga numero.

500 nga mga hangyo matag segundo

Mas makaiikag nga mga butang magsugod nga mahitabo kung ang load moabot sa 500 ka hangyo matag segundo:

Pag-usab, sa ibabaw nga wala nga graph imong makita nga ang aplikasyon nagrekord sa normal nga load. Kung dili kini ang kaso, adunay problema sa server diin ang aplikasyon nagdagan. Ang response latency graph nahimutang sa taas nga tuo, nga nagpakita nga ang 500 ka hangyo kada segundo miresulta sa pagkalangan sa tubag nga 25-40ms. Ang 99th percentile mohaom gihapon sa 60ms SLO nga gipili sa ibabaw.

Sa termino sa gasto:

10000 ka hangyo kada segundo / 500 ka hangyo kada server = 20 ka server + 1

Mapauswag pa ang tanan.

1000 nga mga hangyo matag segundo

Nindot nga paglansad! Gipakita sa aplikasyon nga giproseso niini ang 1000 nga mga hangyo matag segundo, apan ang limitasyon sa latency gilapas sa SLO. Makita kini sa linya p99 sa taas nga tuo nga graph. Bisan pa sa kamatuoran nga ang p100 nga linya mas taas, ang aktuwal nga mga paglangan mas taas kay sa maximum nga 60ms. Atong susihon ang profiling aron mahibal-an kung unsa gyud ang gibuhat sa aplikasyon.

Pag-profile

Alang sa profiling, among gibutang ang load sa 1000 ka hangyo kada segundo, dayon gamiton pprof aron makuha ang datos aron mahibal-an kung diin ang aplikasyon naggasto sa oras sa CPU. Mahimo kini pinaagi sa pagpaaktibo sa HTTP endpoint pprof, ug unya, ubos sa load, i-save ang mga resulta gamit ang curl:

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

Ang mga resulta mahimong ipakita sama niini:

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

Gipakita sa graph kung asa ug pila ang gigugol sa aplikasyon sa oras sa CPU. Gikan sa paghulagway gikan sa Brendan Gregg:

Ang X axis mao ang stack profile populasyon, gisunod-sunod sa alpabetiko (kini dili panahon), ang Y axis nagpakita sa giladmon sa stack, pag-ihap gikan sa zero sa [ibabaw]. Ang matag rektanggulo usa ka stack frame. Ang mas lapad nga frame, mas kanunay kini anaa sa mga stack. Unsa ang naa sa ibabaw nagdagan sa CPU, ug ang naa sa ubos mao ang mga elemento sa bata. Ang mga kolor kasagaran walay kahulogan, apan gipili lang nga random aron magkalahi ang mga frame.

Pagtuki - pangagpas

Alang sa pag-tune, mag-focus kami sa pagsulay sa pagpangita sa nausik nga oras sa CPU. Atong pangitaon ang pinakadako nga tinubdan sa walay pulos nga paggasto ug tangtangon kini. Aw, tungod kay ang profiling nagpadayag nga tukma kaayo kung diin eksakto nga gigugol sa aplikasyon ang oras sa pagproseso niini, mahimo nimo kini buhaton sa daghang mga higayon, ug kinahanglan usab nimo nga usbon ang source code sa aplikasyon, ipadayon ang mga pagsulay ug tan-awa nga ang pasundayag nagkaduol sa target.

Pagsunod sa mga rekomendasyon ni Brendan Gregg, among basahon ang tsart gikan sa taas hangtod sa ubos. Ang matag linya nagpakita og stack frame (function call). Ang una nga linya mao ang entry point sa programa, ang ginikanan sa tanan nga uban nga mga tawag (sa ato pa, ang tanan nga ubang mga tawag adunay kini sa ilang stack). Ang sunod nga linya lahi na:

Kung imong i-hover ang cursor sa ngalan sa usa ka function sa graph, ang kinatibuk-ang oras nga naa sa stack sa panahon sa pag-debug ipakita. Ang HTTPServe function anaa didto 65% sa panahon, uban pang mga runtime function runtime.mcall, mstart и gc, mikuha sa nahabilin nga oras. Makalingaw nga kamatuoran: 5% sa kinatibuk-ang oras ang gigugol sa mga pangutana sa DNS:

Ang mga adres nga gipangita sa programa iya sa Postgresql. Pag-klik sa FindByAge:

Makapainteres, ang programa nagpakita nga, sa prinsipyo, adunay tulo ka nag-unang mga tinubdan nga nagdugang sa mga paglangan: pag-abli ug pagsira sa mga koneksyon, paghangyo sa datos, ug pagkonektar sa database. Gipakita sa graph nga ang mga hangyo sa DNS, pag-abli ug pagsira sa mga koneksyon mokabat sa 13% sa kinatibuk-ang oras sa pagpatuman.

Pangagpas: Ang paggamit pag-usab sa mga koneksyon gamit ang pooling kinahanglan nga makunhuran ang oras sa usa ka hangyo sa HTTP, nga nagtugot sa mas taas nga throughput ug mas ubos nga latency.

Pag-set up sa aplikasyon - eksperimento

Gi-update namo ang source code, sulayi nga tangtangon ang koneksyon sa Postgresql alang sa matag hangyo. Ang una nga kapilian mao ang paggamit koneksyon pool sa lebel sa aplikasyon. Niini nga eksperimento kita atong i-set up koneksyon pooling gamit ang sql driver para sa go:

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

if err != nil {
   return nil, err
}

Pagpatuman, obserbasyon, pagtuki

Human ma-restart ang pagsulay nga adunay 1000 nga mga hangyo matag segundo, klaro nga ang lebel sa latency sa p99 mibalik sa normal nga adunay SLO nga 60ms!

Unsa ang gasto?

10000 ka hangyo kada segundo / 1000 ka hangyo kada server = 10 ka server + 1

Ato kining buhaton nga mas maayo pa!

2000 nga mga hangyo matag segundo

Ang pagdoble sa load nagpakita sa samang butang, ang ibabaw nga wala nga graph nagpakita nga ang aplikasyon nagdumala sa pagproseso sa 2000 nga mga hangyo kada segundo, ang p100 mas ubos kay sa 60ms, ang p99 nagtagbaw sa SLO.

Sa termino sa gasto:

10000 ka hangyo kada segundo / 2000 ka hangyo kada server = 5 ka server + 1

3000 nga mga hangyo matag segundo

Dinhi ang aplikasyon makaproseso sa 3000 nga mga hangyo nga adunay p99 latency nga ubos sa 60ms. Ang SLO wala gilapas, ug ang gasto gidawat ingon sa mosunod:

10000 ka hangyo kada segundo / kada 3000 ka hangyo kada server = 4 ka server + 1 (Ang tagsulat nagtipon, gibanabana. tighubad)

Atong sulayan ang laing hugna sa pagtuki.

Pagtuki - pangagpas

Among gikolekta ug gipakita ang mga resulta sa pag-debug sa aplikasyon sa 3000 ka hangyo kada segundo:

Sa gihapon 6% sa oras ang gigugol sa pagtukod og mga koneksyon. Ang pag-set up sa pool nakapauswag sa pasundayag, apan makita gihapon nimo nga ang aplikasyon nagpadayon sa pagtrabaho sa paghimo og bag-ong mga koneksyon sa database.

Pangagpas: Ang mga koneksyon, bisan pa sa presensya sa usa ka pool, gihulog gihapon ug gilimpyohan, mao nga ang aplikasyon kinahanglan nga i-reset kini. Ang pagtakda sa gidaghanon sa mga pending nga koneksyon sa gidak-on sa pool kinahanglan makatabang sa latency pinaagi sa pagminus sa oras nga gigugol sa aplikasyon sa paghimo og koneksyon.

Pag-set up sa aplikasyon - eksperimento

Naningkamot sa pag-instalar MaxIdleConns katumbas sa gidak-on sa pool (gihulagway usab dinhi):

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

Pagpatuman, obserbasyon, pagtuki

3000 nga mga hangyo matag segundo

Ang p99 dili mubu sa 60ms nga adunay labi ka gamay nga p100!

Ang pagsusi sa flame graph nagpakita nga ang koneksyon dili na mamatikdan! Atong susihon sa mas detalyado pg(*conn).query - wala usab namo namatikdan ang koneksyon nga gitukod dinhi.

konklusyon

Ang pag-analisar sa pasundayag hinungdanon aron masabtan nga ang mga gipaabut sa kostumer ug ang mga kinahanglanon nga dili magamit natuman. Ang pag-analisar pinaagi sa pagtandi sa mga obserbasyon sa mga gipaabut sa kostumer makatabang sa pagtino kung unsa ang madawat ug kung unsa ang dili. Naghatag ang Go og kusgan nga mga himan nga gitukod sa sukaranan nga librarya nga naghimo sa pag-analisar nga yano ug dali ma-access.

Source: www.habr.com