Samaradorlikni tahlil qilish va sozlash mijozlar uchun ishlashni moslashtirishning kuchli vositasidir.
Ishlash tahlili sozlash tajribalarini sinab ko'rishga ilmiy yondashuvni qo'llash orqali dasturdagi to'siqlarni tekshirish uchun ishlatilishi mumkin. Ushbu maqola misol sifatida Go veb-serveridan foydalangan holda ishlash tahlili va sozlashning umumiy yondashuvini belgilaydi.
Go bu erda ayniqsa mos keladi, chunki unda profil yaratish vositalari mavjud. pprof standart kutubxonada.
Strategiya
Keling, tuzilmaviy tahlilimiz uchun xulosa ro'yxatini tuzamiz. Biz sezgi yoki taxminlarga asoslangan o'zgarishlar o'rniga qaror qabul qilish uchun ba'zi ma'lumotlardan foydalanishga harakat qilamiz. Buning uchun, keling, buni qilaylik:
- Biz optimallashtirish chegaralarini aniqlaymiz (talablar);
- Tizim uchun tranzaksiya yukini hisoblaymiz;
- Biz testni bajaramiz (ma'lumotlarni yaratamiz);
- tomosha qilish;
- Biz barcha talablar bajarilganligini tahlil qilamizmi?
- Biz ilmiy yo'l bilan o'rnatamiz, biz faraz qilamiz;
- Ushbu gipotezani tekshirish uchun biz tajriba o'tkazamiz.
Oddiy HTTP server arxitekturasi
Ushbu maqola uchun biz kichik Golang HTTP serveridan foydalanamiz. Ushbu maqoladagi barcha kodlarni topish mumkin .
Tahlil qilinayotgan ilova har bir so'rov uchun Postgresql so'rovini o'tkazadigan HTTP serveridir. Bundan tashqari, dastur va tizim ko'rsatkichlarini to'plash va ko'rsatish uchun Prometheus, node_exporter va Grafana mavjud.
Oddiylik uchun biz gorizontal masshtablash (va hisob-kitoblarni soddalashtirish) uchun har bir xizmat va ma'lumotlar bazasi birgalikda joylashtirilganligini ko'rib chiqamiz:
Biz maqsadlarni aniqlaymiz
Ushbu bosqichda biz maqsadni aniqlaymiz. Biz nimani tahlil qilmoqchimiz? Qachon tugatish vaqti kelganini qanday bilamiz? Ushbu maqolada biz mijozlarimiz borligini va bizning xizmatimiz soniyada 10 000 ta so'rovni amalga oshirishini tasavvur qilamiz.
В tanlash va modellashtirish usullari batafsil ko'rib chiqiladi. Keling, xuddi shunday qilamiz, modellarni yaratamiz:
- Kechikish: so'rovlarning 99% 60ms dan kamroq vaqt ichida bajarilishi kerak;
- Xarajat: Xizmat biz o'ylagancha, mumkin bo'lgan minimal pul miqdorini iste'mol qilishi kerak. Buning uchun biz o'tkazish qobiliyatini maksimal darajada oshiramiz;
- Imkoniyatlarni rejalashtirish: Qancha dastur namunalarini ishga tushirish kerakligini tushunish va hujjatlashtirish, shu jumladan umumiy masshtablash xususiyati va dastlabki yuklash va ta'minlash talablariga javob berish uchun qancha nusxa kerak bo'ladi .
Kechikish tahlilga qo'shimcha ravishda optimallashtirishni talab qilishi mumkin, ammo o'tkazish qobiliyati aniq tahlil qilinishi kerak. SRE SLO jarayonidan foydalanganda, kechiktirish so'rovi mahsulot egasi tomonidan taqdim etilgan mijoz va/yoki biznesdan keladi. Va bizning xizmatimiz bu majburiyatni boshidanoq hech qanday sozlamalarsiz bajaradi!
Sinov muhitini o'rnatish
Sinov muhiti yordamida biz tizimimizga dozalangan yukni chiqarishimiz mumkin bo'ladi. Tahlil qilish uchun veb-xizmat samaradorligi ma'lumotlari yaratiladi.
Tranzaksiya yuki
Bu muhitdan foydalanadi to'xtatilgunga qadar maxsus HTTP so'rov tezligini yaratish uchun:
$ 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 reportKuzatish
Ishlash vaqtida tranzaksiya yuki qo'llaniladi. Ilova ko'rsatkichlari (so'rovlar soni, javob kutish vaqti) va operatsion tizim (xotira, protsessor, IOPS) bilan bir qatorda, qayerda muammolar borligini, shuningdek, protsessor vaqti qanday sarflanishini tushunish uchun dastur profilini yaratish amalga oshiriladi.
Profil yaratish
Profillash - bu dastur ishlayotgan paytda CPU vaqti qayerga ketishini ko'rish imkonini beruvchi o'lchov turi. Bu sizga protsessor vaqti qayerda va qancha ishlayotganini aniq aniqlash imkonini beradi:
Ushbu ma'lumotlardan CPU vaqtini behuda sarflash va keraksiz ishlar haqida tasavvurga ega bo'lish uchun tahlil paytida foydalanish mumkin. Go (pprof) standart asboblar to'plamidan foydalanib profillarni yaratishi va ularni olovli grafik sifatida ko'rsatishi mumkin. Men ulardan foydalanish va sozlash bo'yicha qo'llanmani biroz keyinroq maqolada ko'rib chiqaman.
Amalga oshirish, kuzatish, tahlil qilish.
Keling, tajriba qilaylik. Spektakl bizga mos kelguncha bajaramiz, kuzatamiz va tahlil qilamiz. Birinchi kuzatishlar natijalarini olish uchun uni qo'llash uchun biz o'zboshimchalik bilan past yuk qiymatini tanlaymiz. Har bir keyingi bosqichda biz yukni bir oz tarqalish bilan tanlangan miqyoslash omili bilan oshiramiz. Har bir yuk sinovi so'rovlar soni sozlangan holda amalga oshiriladi: make load-test LOAD_TEST_RATE=X.
Bir soniyada 50 ta so'rov
Yuqoridagi ikkita grafikaga e'tibor bering. Yuqori chap tomonda bizning ilovamiz sekundiga 50 ta so'rovni ko'rib chiqayotganini ko'rsatadi (uning fikricha), yuqori o'ngda esa har bir so'rovning davomiyligi. Ikkala parametr ham bizning ishlash chegaramizga mos keladimi yoki yo'qmi, tekshirish va tahlil qilishimizga yordam beradi. Grafikdagi qizil chiziq HTTP so'rovining kechikishi 60ms da SLO ko'rsatadi. Chiziqdan biz maksimal javob vaqtimizdan ancha past ekanligimizni ko'rishingiz mumkin.
Keling, narxni ko'rib chiqaylik:
Bir soniyada 10000 50 ta so'rov / har bir server uchun 200 ta so'rov = 1 server + XNUMX
Biz bu ko'rsatkichni hali ham yaxshilashimiz mumkin.
Bir soniyada 500 ta so'rov
Yuk sekundiga 500 ta so'rov bo'lganda qiziqroq narsalar boshlanadi:
Shunga qaramay, yuqori chap grafikda dastur odatdagi yukni ushlab turishini ko'rishingiz mumkin. Agar bunday bo'lmasa, dastur ishlayotgan serverda muammo bor. Yuqori o‘ng tarafdagi javob kechikish grafigi shuni ko‘rsatadiki, soniyasiga 500 ta so‘rov 25-40 ms javob kechikishiga olib kelgan. 99-persentil yuqorida tanlangan 60ms SLOga yaxshi mos keladi.
Narxlari bo'yicha:
Bir soniyada 10000 500 ta so'rov / har bir server uchun 20 ta so'rov = 1 server + XNUMX
Hali ham yaxshilash mumkin.
Bir soniyada 1000 ta so'rov
Ajoyib ishga tushirish! Ilova sekundiga 1000 ta so'rovni qayta ishlaganligini ko'rsatadi, ammo kechikish chegarasi SLO tomonidan buzilgan. Buni yuqori o'ng grafikdagi p99 chizig'idan ko'rish mumkin. p100 liniyasi ancha yuqori bo'lsa ham, haqiqiy kechikishlar maksimal 60ms dan yuqori. Ilova aslida nima qilishini bilish uchun profil yaratishga sho'ng'iymiz.
Profil yaratish
Profillash uchun biz yukni soniyada 1000 ta so'rovga o'rnatdik, keyin foydalaning pprof ilova CPU vaqtini qayerga sarflayotganini bilish uchun ma'lumotlarni olish. Buni HTTP so'nggi nuqtasini faollashtirish orqali amalga oshirish mumkin pprof, shundan so'ng yuklashda natijalarni curl yordamida saqlang:
$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.profNatijalar quyidagicha ko'rsatilishi mumkin:
$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof
Grafik dastur protsessor vaqtini qayerda va qancha sarflashini ko'rsatadi. Tavsifdan :
X o'qi - stek profilini to'ldirish, alifbo tartibida tartiblangan (vaqt emas), y o'qi [yuqorida] noldan boshlab stek chuqurligini ko'rsatadi. Har bir to'rtburchaklar stek ramkasidir. Ramka qanchalik keng bo'lsa, u tez-tez stacklarda mavjud. Yuqoridagisi protsessorda ishlaydi, pastdagisi esa bola elementlardir. Ranglar odatda hech narsani anglatmaydi, lekin ramkalarni ajratish uchun tasodifiy tanlanadi.
Tahlil - gipoteza
O'zgartirish uchun biz CPU vaqtini behuda sarflashga harakat qilamiz. Biz chiqindilarning eng katta manbalarini qidiramiz va ularni olib tashlaymiz. Xo'sh, profil yaratish dastur protsessor vaqtini aniq qayerda sarflayotganini aniq ko'rsatganligini hisobga olsak, buni bir necha marta bajarishingiz kerak bo'lishi mumkin, shuningdek, dasturning manba kodini o'zgartirishingiz, testlarni qaytadan o'tkazishingiz va unumdorlik ko'rsatilganiga yaqinlashishini ko'rishingiz kerak bo'ladi. .
Brendan Gregg tavsiyalaridan so'ng biz jadvalni yuqoridan pastga qarab o'qiymiz. Har bir satr stek ramkasini ko'rsatadi (funktsiya chaqiruvi). Birinchi qator dasturga kirish nuqtasi, boshqa barcha qo'ng'iroqlarning ota-onasi (boshqacha qilib aytganda, boshqa barcha qo'ng'iroqlar o'z stekida bo'ladi). Keyingi qator allaqachon boshqacha:
Agar kursorni grafikdagi funksiya nomi ustiga olib kelsangiz, disk raskadrovka paytida uning stekda bo‘lgan umumiy vaqti ko‘rsatiladi. HTTPServe funksiyasi vaqtning 65 foizida, boshqa funksiyalar ish vaqti, runtime.mcall, mstart и gcqolgan vaqtni oldi. Qiziqarli fakt: umumiy vaqtning 5% DNS so'rovlariga sarflanadi:
Dastur qidirayotgan manzillar Postgresql ga tegishli. ni bosing FindByAge:
Qizig'i shundaki, dastur printsipial jihatdan kechikishlarni qo'shadigan uchta asosiy manba mavjudligini ko'rsatadi: ulanishlarni ochish/yopish, ma'lumotlarni so'rash va ma'lumotlar bazasiga ulanish. Grafik shuni ko'rsatadiki, DNS so'rovlari, ulanishlarni ochish va yopish umumiy bajarish vaqtining taxminan 13% ni oladi.
Gipoteza: Birlashma yordamida ulanishlarni qayta ishlatish HTTP orqali bitta so'rov vaqtini qisqartirishi, yuqori o'tkazuvchanlik va past kechikish imkonini beradi..
Ilovani sozlash - tajriba
Biz manba kodini yangilaymiz, har bir so'rov uchun Postgresql-ga ulanishni olib tashlashga harakat qilamiz. Birinchi variant - foydalanish dastur darajasida. Ushbu tajribada biz borish uchun sql drayveri bilan ulanishni birlashtirish:
db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
if err != nil {
return nil, err
}Bajarish, kuzatish, tahlil qilish
Sinovni sekundiga 1000 ta so'rov bilan qayta ishga tushirgandan so'ng, p99 kechikishi 60 ms SLO bilan qaytarilgani aniq!
Narxi qancha?
Bir soniyada 10000 1000 ta so'rov / har bir server uchun 10 ta so'rov = 1 server + XNUMX
Keling, buni yanada yaxshi qilaylik!
Bir soniyada 2000 ta so'rov
Yukni ikki baravar oshirish xuddi shu narsani ko'rsatadi, yuqori chap grafik dastur soniyada 2000 ta so'rovni qayta ishlashga qodirligini ko'rsatadi, p100 60ms dan past, p99 SLOni qondiradi.
Narxlari bo'yicha:
Bir soniyada 10000 2000 ta so'rov / har bir server uchun 5 ta so'rov = 1 server + XNUMX
Bir soniyada 3000 ta so'rov
Bu yerda ilova p3000 kechikishi 99ms dan kam boʻlgan 60 ta soʻrovni qayta ishlay oladi. SLO buzilmaydi va xarajat quyidagicha qabul qilinadi:
Bir soniyada 10000 ta so'rov / har bir server uchun 3000 ta so'rov = 4 server + 1 (muallif eng yaqingacha yaxlitlangan taxminan. tarjimon)
Keling, tahlilning yana bir bosqichini sinab ko'raylik.
Tahlil - gipoteza
Biz ilovani disk raskadrovka natijalarini soniyasiga 3000 ta so'rovda yig'amiz va ko'rsatamiz:
Hali ham vaqtning 6% ulanishlarni o'rnatishga sarflanadi. Hovuzni sozlash unumdorlikni oshirdi, ammo siz hali ham dastur ma'lumotlar bazasiga yangi ulanishlar yaratishda davom etayotganini ko'rishingiz mumkin.
Gipoteza: Ulanishlar, birlashtirilgan bo'lishiga qaramay, hali ham o'chirilmoqda va tozalanmoqda, shuning uchun ilova ularni qayta tiklashi kerak. Hovuz hajmiga kutilayotgan ulanishlar sonini belgilash ilovaning ulanishni yaratish uchun sarflagan vaqtini kamaytirish orqali kechikishni kamaytirishga yordam beradi..
Ilovani sozlash - tajriba
Oʻrnatishga harakat qilinmoqda hovuz hajmiga teng (shuningdek tasvirlangan ):
db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
return nil, err
}Bajarish, kuzatish, tahlil qilish
Bir soniyada 3000 ta so'rov
p99 ancha kichikroq p60 bilan 100ms dan kam!
Olov grafigini tekshirish aloqaning endi ko'rinmasligini ko'rsatadi! Batafsil tekshirish pg(*conn).query - bu erda ham aloqani sezmang.
xulosa
Ishlash tahlili mijozlar kutganlari va funktsional bo'lmagan talablar qondirilayotganligini tushunish uchun juda muhimdir. Kuzatishlarni mijozlar kutganlari bilan solishtirish orqali tahlil qilish nima maqbul va nima emasligini aniqlashga yordam beradi. Go tahlil qilishni sodda va qulay qilish uchun standart kutubxonaga o'rnatilgan kuchli vositalarni taqdim etadi.
Manba: www.habr.com