SRE: ڪارڪردگي جو تجزيو. Go ۾ سادي ويب سرور استعمال ڪندي ترتيب ڏيڻ جو طريقو

ڪارڪردگي جو تجزيو ۽ ٽيوننگ هڪ طاقتور اوزار آهي گراهڪن لاءِ ڪارڪردگي جي تعميل جي تصديق ڪرڻ لاءِ.

ڪارڪردگي تجزيي کي استعمال ڪري سگهجي ٿو هڪ پروگرام ۾ رڪاوٽن جي جانچ ڪرڻ لاءِ سائنسي طريقي کي لاڳو ڪندي ٽيوننگ تجربن کي جانچڻ لاءِ. هي آرٽيڪل وضاحت ڪري ٿو هڪ عام طريقي جي ڪارڪردگي جي تجزيي ۽ ٽيوننگ لاء، هڪ مثال طور Go webserver استعمال ڪندي.

Go هتي خاص طور تي سٺو آهي ڇاڪاڻ ته ان ۾ پروفائلنگ جا اوزار آهن pprof معياري لائبريري ۾.

هن جي حڪمت

اچو ته اسان جي ساخت جي تجزيي لاءِ هڪ خلاصو لسٽ ٺاهيو. اسان ڪوشش ڪنداسين ڪجھ ڊيٽا استعمال ڪرڻ جي بدران فيصلا ڪرڻ لاءِ وجدان يا اندازي جي بنياد تي تبديليون ڪرڻ جي. هن کي ڪرڻ لاءِ اسان هي ڪنداسين:

• اسان اصلاح جون حدون مقرر ڪريون ٿا (گهربل ضرورتون)؛
• اسان حساب ڪريون ٿا ٽرانزيڪشن لوڊ سسٽم لاءِ؛
• اسان ٽيسٽ انجام ڏيون ٿا (ڊيٽا ٺاهي)؛
• اسان مشاهدو ڪيو؛
• اسان تجزيو ڪريون ٿا - ڇا سڀئي گهرجون پوريون ڪيون ويون آهن؟
• اسان ان کي سائنسي طور تي قائم ڪيو، هڪ مفروضو ٺاهيو؛
• اسان هن مفروضي کي جانچڻ لاءِ هڪ تجربو ڪريون ٿا.

سادي HTTP سرور آرڪيٽيڪچر

ھن آرٽيڪل لاءِ اسين استعمال ڪنداسين ھڪڙو ننڍڙو HTTP سرور گولانگ ۾. هن آرٽيڪل مان سڀ ڪوڊ ڳولي سگهجن ٿا هتي.

ايپليڪيشن جو تجزيو ڪيو پيو وڃي هڪ HTTP سرور آهي جيڪو هر درخواست لاءِ Postgresql پول ڪري ٿو. اضافي طور تي، اتي آهي Prometheus، node_exporter ۽ Grafana ايپليڪيشن ۽ سسٽم ميٽرڪس گڏ ڪرڻ ۽ ڊسپلي ڪرڻ لاء.

آسان ڪرڻ لاءِ، اسان غور ڪريون ٿا ته افقي اسڪيلنگ (۽ حسابن کي آسان ڪرڻ) لاءِ هر خدمت ۽ ڊيٽابيس گڏ ٿيل آهن:

مقصدن جي تعريف

هن قدم تي، اسان مقصد تي فيصلو ڪيو. اسان ڇا تجزيو ڪرڻ جي ڪوشش ڪري رهيا آهيون؟ اسان ڪيئن ڄاڻون ٿا ته اهو وقت ختم ٿيڻ جو وقت آهي؟ هن آرٽيڪل ۾، اسان تصور ڪنداسين ته اسان وٽ گراهڪ آهن ۽ اسان جي خدمت في سيڪنڊ 10 درخواستن تي عمل ڪندي.

В گوگل SRE ڪتاب چونڊ ۽ ماڊلنگ جا طريقا تفصيل سان بيان ڪيا ويا آهن. اچو ته ساڳيو ڪم ڪريون ۽ ماڊل ٺاهي:

• ويڪرائي: 99٪ درخواستن کي 60ms کان گهٽ ۾ مڪمل ڪيو وڃي.
• قيمت: خدمت کي گھٽ ۾ گھٽ رقم استعمال ڪرڻ گھرجي جيڪا اسان سمجھون ٿا معقول طور تي ممڪن آھي. هن کي ڪرڻ لاء، اسان throughput وڌ کان وڌ؛
• ظرفيت جي منصوبه بندي: سمجھڻ ۽ دستاويز ڪرڻ جي ضرورت آهي ته ايپليڪيشن جا ڪيترا مثال هلائڻ جي ضرورت پوندي، بشمول مجموعي اسڪيلنگ ڪارڪردگي، ۽ ابتدائي لوڊ ۽ روزي جي ضرورتن کي پورا ڪرڻ لاء ڪيترا مثال گهربل هوندا. بيڪار ن + 1.

دير جي ضرورت ٿي سگھي ٿي تجزيي کان علاوه اصلاح جي، پر throughput واضح طور تي تجزيو ڪرڻ جي ضرورت آهي. جڏهن استعمال ڪندي 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

نظرثاني

ٽرانزيڪشن لوڊ رن ٽائم تي لاڳو ڪيو ويندو. ايپليڪيشن (درخواستن جو تعداد، جواب جي دير) ۽ آپريٽنگ سسٽم (ميموري، سي پي يو، 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 ڊيٽا کي پڪڙڻ لاءِ معلوم ڪرڻ لاءِ ته ايپليڪيشن ڪٿي خرچ ڪري رهي آهي سي پي يو جو وقت. اهو ٿي سگهي ٿو 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

گراف ڏيکاري ٿو ڪٿي ۽ ڪيترو ايپليڪيشن سي پي يو وقت خرچ ڪري ٿي. جي وضاحت کان برينڊن گريگ:

X محور اسٽيڪ پروفائل آبادي آھي، الفابيٽ جي ترتيب سان ترتيب ڏنل آھي (ھي وقت نه آھي)، Y محور اسٽيڪ جي کوٽائي ڏيکاري ٿو، صفر کان ڳڻڻ [مٿي]. هر مستطيل هڪ اسٽيڪ فريم آهي. فريم جيترو وسيع هوندو، اوترو ئي اهو اسٽيڪ ۾ موجود هوندو آهي. مٿي تي ڇا آهي سي پي يو تي هلندو آهي، ۽ هيٺ ڇا آهي ٻار عناصر آهن. رنگن جو عام طور تي ڪو به مطلب نه هوندو آهي، پر رڳو فريم کي فرق ڪرڻ لاءِ بي ترتيب طور چونڊيو ويندو آهي.

تجزيو- مفروضو

ٽيوننگ لاءِ، اسان فضول CPU وقت ڳولڻ جي ڪوشش تي ڌيان ڏينداسين. اسان بيڪار خرچن جا وڏا ذريعا ڳولينداسين ۽ انهن کي ختم ڪنداسين. يقينن، ڏنو ويو آهي ته پروفائلنگ بلڪل صحيح طور تي ظاهر ڪري ٿي جتي ايپليڪيشن پنهنجي پروسيسر جو وقت خرچ ڪري رهي آهي، توهان کي شايد ڪيترائي ڀيرا ڪرڻو پوندو، ۽ توهان کي ايپليڪيشن جو سورس ڪوڊ پڻ تبديل ڪرڻو پوندو، ٽيسٽ کي ٻيهر هلايو ۽ ڏسو ته ڪارڪردگي ٽارگيٽ تائين پهچي ٿي.

برينڊن گريگ جي سفارشن تي عمل ڪندي، اسين پڙھنداسين چارٽ مٿي کان ھيٺ تائين. هر لڪير هڪ اسٽيڪ فريم ڏيکاري ٿو (فنڪشن ڪال). پهرين لائن پروگرام ۾ داخل ٿيڻ واري پوائنٽ آهي، ٻين سڀني ڪالن جو والدين (ٻين لفظن ۾، ٻين سڀني ڪالن کي ان جي اسٽيڪ تي هوندو). ايندڙ لائن اڳ ۾ ئي مختلف آهي:

جيڪڏهن توهان گراف تي هڪ فنڪشن جي نالي تي ڪرسر کي هور ڪريو ٿا، مجموعي وقت ڏيکاري ويندي جيڪا ڊيبگنگ دوران اسٽيڪ تي هئي. HTTPServe فنڪشن اتي موجود هو 65٪ وقت، ٻيا رن ٽائم افعال runtime.mcall, mstart и gc، باقي وقت ورتو. مذاق حقيقت: ڪل وقت جو 5٪ DNS سوالن تي خرچ ڪيو ويو آهي:

ايڊريس جيڪي پروگرام ڳولي رهيا آهن انهن جو تعلق Postgresql سان آهي. تي ڪلڪ ڪريو FindByAge:

دلچسپ ڳالهه اها آهي ته، پروگرام ڏيکاري ٿو، اصول ۾، ٽي مکيه ذريعا آهن جيڪي دير سان شامل ڪن ٿا: ڪنيڪشن کولڻ ۽ بند ڪرڻ، ڊيٽا جي درخواست ڪرڻ، ۽ ڊيٽابيس سان ڳنڍڻ. گراف ڏيکاري ٿو ته DNS درخواستون، کولڻ ۽ بند ڪرڻ وارا ڪنيڪشن لڳ ڀڳ 13 سيڪڙو لڳن ٿا مجموعي عمل جي وقت جو.

مفروضو: پولنگ استعمال ڪندي ڪنيڪشن کي ٻيهر استعمال ڪرڻ گهرجي هڪ واحد HTTP درخواست جي وقت کي گھٽائڻ، اجازت ڏيڻ جي اجازت ڏئي اعلي throughput ۽ گھٽ ويڪرائي.

ايپليڪيشن کي ترتيب ڏيڻ - تجربو

اسان ماخذ ڪوڊ کي تازه ڪاري ڪريون ٿا، هر درخواست لاء پوسٽ گريسڪ ايل سان ڪنيڪشن کي هٽائڻ جي ڪوشش ڪريو. پهريون اختيار استعمال ڪرڻ آهي ڪنيڪشن پول اپليڪيشن جي سطح تي. هن تجربي ۾ اسان اچو ته ان کي ترتيب ڏيو وڃڻ لاءِ 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 درخواستون في سيڪنڊ

هتي ايپليڪيشن 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 60ms کان گھٽ آھي خاص طور تي گھٽ p100 سان!

شعل گراف جي جانچ ڪندي ڏيکاري ٿو ته ڪنيڪشن هاڻي قابل ذڪر ناهي! اچو ته وڌيڪ تفصيل سان چيڪ ڪريو pg(*conn).query - اسان پڻ نوٽيس نه ڪندا آهيون ڪنيڪشن هتي قائم ٿي رهيو آهي.

ٿڪل

ڪارڪردگي جو تجزيو اهو سمجهڻ لاءِ اهم آهي ته گراهڪ جون اميدون ۽ غير فنڪشنل گهرجون پوريون ٿي رهيون آهن. تجزيي ذريعي مشاهدن جي مقابلي ۾ گراهڪ جي اميدن سان اهو طئي ڪرڻ ۾ مدد ڪري سگھي ٿي ته ڇا قابل قبول آهي ۽ ڇا نه آهي. Go مهيا ڪري ٿو طاقتور اوزار جيڪي معياري لائبريري ۾ ٺاهيا ويا آهن جيڪي تجزيو کي آسان ۽ رسائي لائق بڻائين ٿا.

جو ذريعو: www.habr.com