د فعالیت تحلیل او ټونینګ د پیرودونکو لپاره د فعالیت موافقت تصدیق کولو لپاره قوي وسیله ده.
د فعالیت تحلیل د ټونینګ تجربو ازموینې لپاره د ساینسي چلند په پلي کولو سره په برنامه کې د خنډونو چیک کولو لپاره کارول کیدی شي. دا مقاله د فعالیت تحلیل او تونګ کولو لپاره عمومي چلند تعریفوي ، د مثال په توګه د Go ویب سرور په کارولو سره.
Go دلته په ځانګړي ډول ښه دی ځکه چې دا د پروفایل کولو وسیلې لري pprof په معیاري کتابتون کې.
ستراتیژي
راځئ چې زموږ د ساختماني تحلیل لپاره لنډیز لیست جوړ کړو. موږ به هڅه وکړو چې ځینې معلومات وکاروو ترڅو د پریکړو کولو پر ځای د تعقل یا اټکل پراساس بدلونونه رامینځته کړو. د دې کولو لپاره موږ به دا کار وکړو:
- موږ د اصلاح کولو حدود ټاکو (اړتیاوې)؛
- موږ د سیسټم لپاره د لیږد بار محاسبه کوو؛
- موږ ازموینه ترسره کوو (ډیټا رامینځته کړئ)؛
- موږ ګورو؛
- موږ تحلیل کوو - ایا ټولې اړتیاوې پوره شوې؟
- موږ دا په ساینسي ډول ترتیب کړه، فرضیه جوړه کړه؛
- موږ د دې فرضیې ازموینې لپاره تجربه ترسره کوو.
ساده HTTP سرور جوړښت
د دې مقالې لپاره موږ به په ګولنګ کې یو کوچنی HTTP سرور وکاروو. د دې مقالې ټول کوډ موندل کیدی شي .
هغه غوښتنلیک چې تحلیل کیږي د HTTP سرور دی چې د هرې غوښتنې لپاره Postgresql رایه ورکوي. سربیره پردې ، د غوښتنلیک او سیسټم میټریکونو راټولولو او ښودلو لپاره پرومیټیوس ، نوډ_ ایکسپورټر او ګرافانا شتون لري.
د ساده کولو لپاره، موږ په پام کې نیسو چې د افقی اندازه کولو لپاره (او د محاسبې ساده کول) هر خدمت او ډیټابیس یوځای ځای پرځای شوي دي:
د اهدافو تعریف
پدې مرحله کې، موږ د هدف په اړه پریکړه کوو. موږ د څه تحلیل هڅه کوو؟ موږ څنګه پوهیږو چې دا د پای وخت دی؟ پدې مقاله کې، موږ به تصور وکړو چې موږ پیرودونکي لرو او دا چې زموږ خدمت به په هره ثانیه کې 10 غوښتنې پروسس کړي.
В د انتخاب او ماډل کولو میتودونه په تفصیل سره بحث شوي. راځئ چې ورته کار وکړو او ماډلونه جوړ کړو:
- ځنډ: 99٪ غوښتنې باید له 60ms څخه لږ وخت کې بشپړې شي؛
- لګښت: خدمت باید لږترلږه پیسې مصرف کړي چې موږ فکر کوو په معقول ډول ممکن وي. د دې کولو لپاره، موږ د تولید کچه لوړه کوو؛
- د ظرفیت پالن کول: د پوهیدو او مستند کولو ته اړتیا لري چې د غوښتنلیک څومره مثالونه به چلولو ته اړتیا ولري، په شمول د ټول اندازه کولو فعالیت، او د لومړني بار او چمتو کولو اړتیاو پوره کولو لپاره به څومره مثالونو ته اړتیا وي. .
ځنډ ممکن د تحلیل سربیره اصلاح کولو ته اړتیا ولري ، مګر په روښانه ډول تحلیل ته اړتیا لري. کله چې د 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 غوښتنه ځنډ SLO په 60ms کې ښیي. کرښه ښیې چې موږ زموږ د اعظمي ځواب وخت څخه ښه یو.
راځئ چې د لګښت اړخ وګورو:
په هر ثانیه کې 10000 غوښتنې / 50 غوښتنې په هر سرور = 200 سرورونه + 1
موږ لاهم کولی شو دا ارقام ښه کړو.
په هره ثانیه کې 500 غوښتنې
ډیر په زړه پوري شیان پیښیږي کله چې بار په هره ثانیه کې 500 غوښتنې ته ورسیږي:
یوځل بیا ، په پورتنۍ کیڼ ګراف کې تاسو لیدلی شئ چې غوښتنلیک نورمال بار ثبتوي. که دا قضیه نده، په سرور کې ستونزه شتون لري چې غوښتنلیک یې روان دی. د غبرګون د ځنډ ګراف په پورتنۍ ښۍ خوا کې موقعیت لري، دا ښیي چې په هر ثانیه کې 500 غوښتنې د 25-40ms د ځواب ځنډ لامل شوي. 99 فیصده لا تر اوسه د پورته غوره شوي 60ms SLO سره په ښه توګه فټ کوي.
د لګښت له مخې:
په هر ثانیه کې 10000 غوښتنې / 500 غوښتنې په هر سرور = 20 سرورونه + 1
هرڅه لاهم ښه کیدی شي.
په هره ثانیه کې 1000 غوښتنې
عالي لانچ! غوښتنلیک ښیي چې دا په هره ثانیه کې 1000 غوښتنې پروسس کوي، مګر د ځنډ محدودیت د SLO لخوا سرغړونه شوې. دا په پورتنۍ ښیې ګراف کې په p99 کرښه کې لیدل کیدی شي. د دې حقیقت سره سره چې د p100 کرښه خورا لوړه ده، اصلي ځنډونه د 60ms څخه لوړ دي. راځئ چې پروفایل کولو ته لاړ شو ترڅو ومومئ چې غوښتنلیک واقعیا څه کوي.
پروفایل کول
د پروفایل کولو لپاره، موږ په هره ثانیه کې 1000 غوښتنو ته بار ټاکلی، بیا یې وکاروو pprof د معلوماتو ترلاسه کولو لپاره ترڅو معلومه کړي چې غوښتنلیک د CPU وخت چیرته مصرفوي. دا د HTTP پای ټکی فعالولو سره ترسره کیدی شي pprof، او بیا، د بار لاندې، د curl په کارولو سره پایلې خوندي کړئ:
$ 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 وخت مصرفوي. له تفصیل څخه :
د ایکس محور د سټیک پروفایل نفوس دی، په الفبا کې ترتیب شوی (دا وخت نه دی)، د 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 غوښتنو سره د غوښتنلیک ډیبګ کولو پایلې راټول او ښکاره کوو:
اوس هم د وخت ۶٪ د اړیکو په جوړولو لګیږي. د حوض تنظیم کول فعالیت ښه کړی ، مګر تاسو لاهم لیدلی شئ چې غوښتنلیک ډیټابیس ته د نوي اړیکو رامینځته کولو کار ته دوام ورکوي.
فرضیه: اتصالات ، د حوض شتون سره سره ، لاهم غورځول شوي او پاک شوي ، نو غوښتنلیک اړتیا لري دوی له سره تنظیم کړي. د حوض اندازې ته د پاتې اړیکو شمیر تنظیم کول باید د ځنډ سره مرسته وکړي د هغه وخت کمولو سره چې غوښتنلیک د ارتباط رامینځته کولو مصرف کوي.
د غوښتنلیک تنظیم کول - تجربه
د نصبولو هڅه کوي د حوض اندازې سره مساوي (هم تشریح شوي ):
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