Analisis kinerja lan tuning minangka alat sing kuat kanggo verifikasi kepatuhan kinerja kanggo klien.
Analisis kinerja bisa digunakake kanggo mriksa bottlenecks ing program kanthi nggunakake pendekatan ilmiah kanggo nguji eksperimen tuning. Artikel iki nemtokake pendekatan umum kanggo analisis kinerja lan tuning, nggunakake server web Go minangka conto.
Go luwih apik ing kene amarga duwe alat profil pprof ing perpustakaan standar.
Strategi
Ayo nggawe dhaptar ringkesan kanggo analisis struktural kita. Kita bakal nyoba nggunakake sawetara data kanggo nggawe keputusan tinimbang nggawe owah-owahan adhedhasar intuisi utawa guesswork. Kanggo nindakake iki, kita bakal nindakake iki:
- Kita nemtokake wates optimasi (syarat);
- Kita ngetung beban transaksi kanggo sistem;
- Kita nindakake tes (nggawe data);
- Kita mirsani;
- We njelasno - kabeh syarat ketemu?
- Kita nyiyapake kanthi ilmiah, nggawe hipotesis;
- Kita nindakake eksperimen kanggo nguji hipotesis iki.
Arsitektur Server HTTP sing prasaja
Kanggo artikel iki kita bakal nggunakake server HTTP cilik ing Golang. Kabeh kode saka artikel iki bisa ditemokake .
Aplikasi sing dianalisis yaiku server HTTP sing polling Postgresql kanggo saben panyuwunan. Kajaba iku, ana Prometheus, node_exporter lan Grafana kanggo ngumpulake lan nampilake metrik aplikasi lan sistem.
Kanggo nyederhanakake, kita nganggep manawa kanggo skala horisontal (lan nyederhanakake petungan) saben layanan lan basis data disebarake bebarengan:
Nemtokake gol
Ing langkah iki, kita mutusake tujuan. Apa sing kita coba analisa? Piyé carané awaké dhéwé ngerti nèk wis wektuné rampung? Ing artikel iki, kita bakal mbayangno yen kita duwe klien lan layanan kita bakal ngolah 10 panjalukan saben detik.
В Cara milih lan modeling dibahas kanthi rinci. Ayo padha nindakake lan mbangun model:
- Latency: 99% panjalukan kudu rampung kurang saka 60ms;
- Biaya: Layanan kudu nggunakake jumlah minimal dhuwit sing kita pikir cukup bisa. Kanggo nindakake iki, kita nggedhekake throughput;
- Perencanaan kapasitas: Mbutuhake pangerten lan dokumentasi babagan pirang-pirang kasus aplikasi sing kudu ditindakake, kalebu fungsi skala sakabèhé, lan pirang-pirang instansi sing dibutuhake kanggo nyukupi syarat muatan awal lan provisioning. .
Latensi bisa uga mbutuhake optimasi saliyane analisis, nanging throughput kanthi jelas kudu dianalisis. Nalika nggunakake proses SRE SLO, panjalukan wektu tundha saka pelanggan utawa bisnis, diwakili dening pemilik produk. Lan layanan kita bakal nepaki kewajiban iki wiwit wiwitan tanpa setelan!
Nyetel lingkungan test
Kanthi bantuan lingkungan tes, kita bakal bisa nyelehake beban sing diukur ing sistem kita. Kanggo analisis, data babagan kinerja layanan web bakal digawe.
Beban transaksi
Lingkungan iki nggunakake kanggo nggawe tingkat panjalukan HTTP khusus nganti mandheg:
$ 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 reportPengamatan
Beban transaksi bakal ditrapake nalika runtime. Saliyane metrik aplikasi (jumlah panjalukan, latensi respon) lan sistem operasi (memori, CPU, IOPS), profil aplikasi bakal ditindakake kanggo mangerteni ing ngendi ana masalah lan carane wektu CPU dikonsumsi.
Profiling
Profiling minangka jinis pangukuran sing ngidini sampeyan ndeleng endi wektu CPU nalika aplikasi lagi mlaku. Iki ngidini sampeyan nemtokake persis ing endi lan pira wektu prosesor digunakake:
Data iki bisa digunakake sajrone analisis kanggo ngerteni babagan wektu CPU sing boroske lan karya sing ora perlu ditindakake. Go (pprof) bisa ngasilake profil lan nggambarake minangka grafik nyala nggunakake piranti standar. Aku bakal ngomong babagan panggunaan lan pandhuan persiyapan mengko ing artikel kasebut.
Eksekusi, observasi, analisis.
Ayo padha nindakake eksperimen. Kita bakal nindakake, mirsani lan nganalisa nganti kita wareg karo kinerja. Ayo kita milih nilai beban sing sithik kanggo ditrapake kanggo entuk asil pengamatan pisanan. Ing saben langkah sabanjure kita bakal nambah beban kanthi faktor skala tartamtu, dipilih kanthi sawetara variasi. Saben uji coba beban ditindakake kanthi jumlah panjaluk sing diatur: make load-test LOAD_TEST_RATE=X.
50 panjalukan saben detik
Pay manungsa waé menyang rong grafik ndhuwur. Ing sisih kiwa ndhuwur nuduhake yen aplikasi kita ngolah 50 panjaluk saben detik (kira-kira) lan sisih tengen ndhuwur nuduhake durasi saben panjaluk. Loro-lorone paramèter mbantu kita ndeleng lan nganalisa apa kita ana ing wates kinerja utawa ora. Garis abang ing grafik Latency Request HTTP nuduhake SLO ing 60ms. Baris kasebut nuduhake yen kita ana ing sangisore wektu respon maksimal.
Ayo katon ing sisih biaya:
10000 panjalukan per detik / 50 panjalukan saben server = 200 server + 1
Kita isih bisa nambah angka iki.
500 panjalukan saben detik
Prekara sing luwih menarik wiwit kedadeyan nalika beban nganti 500 panjaluk saben detik:
Maneh, ing grafik kiwa ndhuwur sampeyan bisa ndeleng manawa aplikasi ngrekam beban normal. Yen ora, ana masalah ing server sing aplikasi kasebut mlaku. Grafik latensi respon dumunung ing sisih tengen ndhuwur, nuduhake yen 500 panjalukan per detik nyebabake wektu tundha respon 25-40ms. Persentil 99 isih pas karo SLO 60ms sing dipilih ing ndhuwur.
Ing babagan biaya:
10000 panjalukan per detik / 500 panjalukan saben server = 20 server + 1
Kabeh isih bisa didandani.
1000 panjalukan saben detik
Bukak gedhe! Aplikasi kasebut nuduhake yen diproses 1000 panjalukan saben detik, nanging watesan latensi dilanggar dening SLO. Iki bisa dideleng ing baris p99 ing grafik sisih ndhuwur. Senadyan kasunyatan manawa garis p100 luwih dhuwur, tundha nyata luwih dhuwur tinimbang maksimal 60ms. Ayo nyilem profiling kanggo ngerteni apa sejatine aplikasi kasebut.
Profiling
Kanggo profiling, kita nyetel beban menyang 1000 panjalukan per detik, banjur gunakake pprof kanggo njupuk data kanggo mangerteni ngendi aplikasi mbuwang wektu CPU. Iki bisa ditindakake kanthi ngaktifake titik pungkasan HTTP pprof, banjur, nalika dimuat, simpen asil nggunakake curl:
$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.profAsil bisa ditampilake kaya iki:
$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof
Grafik kasebut nuduhake ing endi lan pira aplikasi nggunakake wektu CPU. Saka katrangan saka :
Sumbu X minangka populasi profil tumpukan, diurutake miturut abjad (iki dudu wektu), sumbu Y nuduhake ambane tumpukan, ngetang saka nol ing [ndhuwur]. Saben persegi panjang minangka pigura tumpukan. Sing luwih jembar pigura, luwih kerep ana ing tumpukan. Apa ing ndhuwur mlaku ing CPU, lan apa ing ngisor iki unsur anak. Werna biasane ora ateges apa-apa, nanging mung dipilih kanthi acak kanggo mbedakake pigura.
Analisis - hipotesis
Kanggo nyetel, kita bakal fokus ing nyoba golek wektu CPU boroske. Kita bakal nggoleki sumber paling gedhe saka mbuwang ora ana guna lan mbusak mau. Ya, amarga profil kasebut nuduhake kanthi akurat ing endi aplikasi kasebut mbuwang wektu prosesor, sampeyan bisa uga kudu nindakake kaping pirang-pirang, lan sampeyan uga kudu ngganti kode sumber aplikasi, nglakokake maneh tes lan ndeleng manawa kinerja nyedhaki target.
Sawise rekomendasi Brendan Gregg, kita bakal maca grafik saka ndhuwur nganti ngisor. Saben baris nampilake pigura tumpukan (panggilan fungsi). Baris pisanan minangka titik entri menyang program, wong tuwa saka kabeh telpon liyane (ing tembung liyane, kabeh telpon liyane bakal duwe ing tumpukan). Baris sabanjure wis beda:
Yen sampeyan nglayang kursor ing jeneng fungsi ing grafik, total wektu ing tumpukan nalika debugging bakal ditampilake. Fungsi HTTPServe ana 65% wektu, fungsi runtime liyane runtime.mcall, mstart и gc, njupuk wektu liyane. Kasunyatan sing nyenengake: 5% saka total wektu digunakake kanggo pitakon DNS:
Alamat sing digoleki program kasebut kalebu Postgresql. Klik ing FindByAge:
Sing nggumunake, program kasebut nuduhake yen, ing prinsip, ana telung sumber utama sing nambah wektu tundha: mbukak lan nutup sambungan, njaluk data, lan nyambungake menyang database. Grafik kasebut nuduhake manawa panjaluk DNS, sambungan mbukak lan nutup njupuk udakara 13% saka total wektu eksekusi.
Hipotesis: Nggunakake sambungan maneh nggunakake pooling kudu nyuda wektu panjalukan HTTP siji, ngidini throughput sing luwih dhuwur lan latensi sing luwih murah.
Nyiyapake aplikasi - eksperimen
Kita nganyari kode sumber, nyoba mbusak sambungan menyang Postgresql kanggo saben panyuwunan. Opsi pisanan yaiku nggunakake ing tingkat aplikasi. Ing eksperimen iki kita pooling sambungan nggunakake driver sql kanggo go:
db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
if err != nil {
return nil, err
}Eksekusi, observasi, analisis
Sawise miwiti maneh tes kanthi 1000 panjalukan per detik, jelas yen tingkat latensi p99 wis normal maneh kanthi SLO 60ms!
Pira regane?
10000 panjalukan per detik / 1000 panjalukan saben server = 10 server + 1
Ayo dadi luwih apik!
2000 panjalukan saben detik
Dobel mbukak nuduhake bab sing padha, graph kiwa ndhuwur nuduhake yen aplikasi ngatur kanggo proses 2000 panjalukan per detik, p100 luwih murah tinimbang 60ms, p99 gawe marem SLO.
Ing babagan biaya:
10000 panjalukan per detik / 2000 panjalukan saben server = 5 server + 1
3000 panjalukan saben detik
Ing kene aplikasi bisa ngolah 3000 panjalukan kanthi latensi p99 kurang saka 60ms. SLO ora dilanggar, lan biaya ditampa kaya ing ngisor iki:
10000 panjalukan per detik / saben 3000 panjalukan saben server = 4 server + 1 (penulis wis dibunderaké, kira-kira. penerjemah)
Ayo dadi nyoba babak analisis liyane.
Analisis - hipotesis
Kita ngumpulake lan nampilake asil debugging aplikasi ing 3000 panjalukan saben detik:
Isih 6% wektu digunakake kanggo nggawe sambungan. Nyiyapake blumbang wis nambah kinerja, nanging sampeyan isih bisa ndeleng sing aplikasi terus bisa nggawe sambungan anyar kanggo database.
Hipotesis: Sambungan, senadyan ana blumbang, isih dropped lan ngresiki munggah, supaya aplikasi kudu ngreset. Nyetel jumlah sambungan sing ditundha menyang ukuran blumbang kudu mbantu latensi kanthi nyilikake wektu aplikasi nggawe sambungan..
Nyiyapake aplikasi - eksperimen
Nyoba kanggo nginstal padha karo ukuran blumbang (uga diterangake ):
db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
return nil, err
}Eksekusi, observasi, analisis
3000 panjalukan saben detik
p99 kurang saka 60ms kanthi kurang p100!
Priksa grafik nyala nuduhake yen sambungan ora katon maneh! Ayo dipriksa luwih rinci pg(*conn).query - kita uga ora sok dong mirsani sambungan sing ditetepake ing kene.
kesimpulan
Analisis kinerja penting kanggo mangerteni manawa pangarepan pelanggan lan syarat non-fungsional ditindakake. Analisis kanthi mbandhingake pengamatan karo pangarepan pelanggan bisa mbantu nemtokake apa sing bisa ditampa lan apa sing ora. Go nyedhiyakake alat sing kuat sing dibangun ing perpustakaan standar sing nggawe analisis gampang lan bisa diakses.
Source: www.habr.com