SRE: کارکردگی کا تجزیہ۔ گو میں ایک سادہ ویب سرور کا استعمال کرتے ہوئے کنفیگریشن کا طریقہ

کارکردگی کا تجزیہ اور ٹیوننگ کلائنٹس کے لیے کارکردگی کی تعمیل کی تصدیق کے لیے ایک طاقتور ٹول ہے۔

کارکردگی کے تجزیے کا استعمال ٹیوننگ تجربات کی جانچ کے لیے سائنسی نقطہ نظر کا استعمال کرتے ہوئے کسی پروگرام میں رکاوٹوں کو جانچنے کے لیے کیا جا سکتا ہے۔ یہ مضمون گو ویب سرور کو مثال کے طور پر استعمال کرتے ہوئے کارکردگی کے تجزیہ اور ٹیوننگ کے لیے ایک عمومی نقطہ نظر کی وضاحت کرتا ہے۔

Go یہاں خاص طور پر اچھا ہے کیونکہ اس میں پروفائلنگ ٹولز ہیں۔ pprof معیاری لائبریری میں۔

حکمت عملی

آئیے اپنے ساختی تجزیہ کے لیے ایک خلاصہ فہرست بنائیں۔ ہم وجدان یا اندازے کی بنیاد پر تبدیلیاں کرنے کے بجائے فیصلے کرنے کے لیے کچھ ڈیٹا استعمال کرنے کی کوشش کریں گے۔ ایسا کرنے کے لیے ہم یہ کریں گے:

• ہم اصلاح کی حدود کا تعین کرتے ہیں (ضروریات)؛
• ہم سسٹم کے لیے لین دین کے بوجھ کا حساب لگاتے ہیں۔
• ہم ٹیسٹ انجام دیتے ہیں (ڈیٹا بنائیں)؛
• ہم مشاہدہ کرتے ہیں؛
• ہم تجزیہ کرتے ہیں - کیا تمام تقاضے پورے ہوتے ہیں؟
• ہم اسے سائنسی طور پر مرتب کرتے ہیں، ایک مفروضہ بناتے ہیں۔
• ہم اس مفروضے کو جانچنے کے لیے ایک تجربہ کرتے ہیں۔

سادہ HTTP سرور فن تعمیر

اس مضمون کے لیے ہم گولانگ میں ایک چھوٹا HTTP سرور استعمال کریں گے۔ اس مضمون کے تمام کوڈ مل سکتے ہیں۔ یہاں.

جس درخواست کا تجزیہ کیا جا رہا ہے وہ ایک HTTP سرور ہے جو ہر درخواست کے لیے Postgresql کو پول کرتا ہے۔ مزید برآں، ایپلیکیشن اور سسٹم میٹرکس کو جمع کرنے اور ڈسپلے کرنے کے لیے پرومیتھیس، نوڈ_ایکسپورٹر اور گرافانا موجود ہے۔

آسان بنانے کے لیے، ہم غور کرتے ہیں کہ افقی اسکیلنگ (اور حساب کو آسان بنانے) کے لیے ہر سروس اور ڈیٹا بیس کو ایک ساتھ تعینات کیا گیا ہے:

اہداف کا تعین کرنا

اس مرحلے پر، ہم مقصد کا فیصلہ کرتے ہیں۔ ہم کیا تجزیہ کرنے کی کوشش کر رہے ہیں؟ ہم کیسے جانتے ہیں کہ کب ختم ہونے کا وقت ہے؟ اس مضمون میں، ہم تصور کریں گے کہ ہمارے پاس کلائنٹ ہیں اور ہماری سروس فی سیکنڈ 10 درخواستوں پر کارروائی کرے گی۔

В گوگل ایس آر ای بک انتخاب اور ماڈلنگ کے طریقوں پر تفصیل سے بحث کی گئی ہے۔ آئیے ایسا ہی کریں اور ماڈلز بنائیں:

• تاخیر: 99% درخواستیں 60ms سے کم میں مکمل کی جانی چاہئیں۔
• لاگت: سروس کو کم سے کم رقم استعمال کرنی چاہئے جو ہمارے خیال میں معقول حد تک ممکن ہے۔ ایسا کرنے کے لیے، ہم تھرو پٹ کو زیادہ سے زیادہ کرتے ہیں۔
• صلاحیت کی منصوبہ بندی: یہ سمجھنے اور دستاویز کرنے کی ضرورت ہے کہ ایپلیکیشن کی کتنی مثالوں کو چلانے کی ضرورت ہوگی، بشمول مجموعی پیمانے کی فعالیت، اور ابتدائی بوجھ اور فراہمی کی ضروریات کو پورا کرنے کے لیے کتنی مثالوں کی ضرورت ہوگی۔ فالتو پن n+1.

تاخیر کے لیے تجزیہ کے علاوہ اصلاح کی ضرورت پڑ سکتی ہے، لیکن تھرو پٹ کا واضح طور پر تجزیہ کرنے کی ضرورت ہے۔ 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 کا وقت کہاں جا رہا ہے۔ یہ آپ کو یہ تعین کرنے کی اجازت دیتا ہے کہ پروسیسر کا وقت کہاں اور کتنا خرچ ہوتا ہے:

اس ڈیٹا کو تجزیہ کے دوران استعمال کیا جا سکتا ہے تاکہ CPU کے ضائع ہونے والے وقت اور غیر ضروری کام کو انجام دیا جا سکے۔ Go (pprof) ٹولز کے معیاری سیٹ کا استعمال کرتے ہوئے پروفائلز بنا سکتا ہے اور انہیں شعلہ گراف کے طور پر تصور کر سکتا ہے۔ میں مضمون میں بعد میں ان کے استعمال اور سیٹ اپ گائیڈ کے بارے میں بات کروں گا۔

عمل، مشاہدہ، تجزیہ۔

آئیے ایک تجربہ کرتے ہیں۔ جب تک ہم کارکردگی سے مطمئن نہیں ہو جاتے تب تک ہم کارکردگی، مشاہدہ اور تجزیہ کریں گے۔ آئیے پہلے مشاہدات کے نتائج حاصل کرنے کے لیے اسے لاگو کرنے کے لیے من مانی طور پر کم لوڈ ویلیو کا انتخاب کریں۔ ہر بعد کے مرحلے پر ہم ایک مخصوص پیمانے کے عنصر کے ساتھ بوجھ میں اضافہ کریں گے، جسے کچھ تغیرات کے ساتھ منتخب کیا گیا ہے۔ ہر لوڈ ٹیسٹنگ رن کو ایڈجسٹ کردہ درخواستوں کی تعداد کے ساتھ انجام دیا جاتا ہے: make load-test LOAD_TEST_RATE=X.

50 درخواستیں فی سیکنڈ

اوپر کے دو گراف پر توجہ دیں۔ اوپر بائیں طرف سے ظاہر ہوتا ہے کہ ہماری درخواست فی سیکنڈ 50 درخواستوں پر کارروائی کرتی ہے (اس کے خیال میں) اور اوپری دائیں طرف ہر درخواست کی مدت دکھاتا ہے۔ دونوں پیرامیٹرز ہمیں یہ دیکھنے اور تجزیہ کرنے میں مدد کرتے ہیں کہ آیا ہم اپنی کارکردگی کی حدود میں ہیں یا نہیں۔ گراف پر سرخ لکیر HTTP درخواست میں تاخیر 60ms پر SLO دکھاتا ہے۔ لائن سے پتہ چلتا ہے کہ ہم اپنے زیادہ سے زیادہ رسپانس ٹائم سے کافی نیچے ہیں۔

آئیے لاگت کی طرف دیکھتے ہیں:

فی سیکنڈ 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

گراف دکھاتا ہے کہ ایپلی کیشن CPU وقت کہاں اور کتنا خرچ کرتی ہے۔ سے تفصیل سے برینڈن گریگ:

X محور اسٹیک پروفائل کی آبادی ہے، جسے حروف تہجی کے مطابق ترتیب دیا گیا ہے (یہ وقت نہیں ہے)، Y محور اسٹیک کی گہرائی کو ظاہر کرتا ہے، صفر سے [اوپر] پر شمار ہوتا ہے۔ ہر مستطیل ایک اسٹیک فریم ہے۔ فریم جتنا چوڑا ہوتا ہے، اتنا ہی کثرت سے یہ ڈھیروں میں موجود ہوتا ہے۔ جو سب سے اوپر ہے وہ سی پی یو پر چلتا ہے، اور جو نیچے ہے وہ بچے کے عناصر ہیں۔ رنگوں کا عام طور پر کوئی مطلب نہیں ہوتا، لیکن فریموں کو فرق کرنے کے لیے بے ترتیب طور پر منتخب کیا جاتا ہے۔

تجزیہ - مفروضہ

ٹیوننگ کے لیے، ہم ضائع شدہ CPU وقت تلاش کرنے کی کوشش پر توجہ مرکوز کریں گے۔ ہم بیکار اخراجات کے سب سے بڑے ذرائع تلاش کریں گے اور انہیں دور کریں گے۔ ٹھیک ہے، اس حقیقت کو دیکھتے ہوئے کہ پروفائلنگ بالکل درست طریقے سے یہ ظاہر کرتی ہے کہ ایپلی کیشن اپنے پروسیسر کا وقت کہاں خرچ کر رہی ہے، آپ کو کئی بار ایسا کرنا پڑ سکتا ہے، اور آپ کو ایپلیکیشن کے سورس کوڈ کو تبدیل کرنے، ٹیسٹوں کو دوبارہ چلانے اور کارکردگی کو دیکھنے کی ضرورت ہوگی۔ نشانہ.

برینڈن گریگ کی سفارشات کے بعد، ہم چارٹ کو اوپر سے نیچے تک پڑھیں گے۔ ہر لائن ایک اسٹیک فریم (فنکشن کال) دکھاتی ہے۔ پہلی لائن پروگرام میں داخلے کا نقطہ ہے، دوسری تمام کالوں کا پیرنٹ (دوسرے لفظوں میں، دیگر تمام کالوں کے اسٹیک پر ہوگا)۔ اگلی لائن پہلے ہی مختلف ہے:

اگر آپ گراف پر کسی فنکشن کے نام پر کرسر کو ہوور کرتے ہیں، تو ڈیبگنگ کے دوران اسٹیک پر ہونے والا کل وقت ظاہر ہوگا۔ HTTPServe فنکشن وہاں 65% وقت تھا، دوسرے رن ٹائم فنکشنز runtime.mcall, mstart и gc, باقی وقت لیا. تفریحی حقیقت: کل وقت کا 5% DNS سوالات پر خرچ ہوتا ہے:

پروگرام جن پتے کی تلاش کر رہا ہے وہ Postgresql سے تعلق رکھتے ہیں۔ پر کلک کریں FindByAge:

دلچسپ بات یہ ہے کہ پروگرام ظاہر کرتا ہے کہ اصولی طور پر تین اہم ذرائع ہیں جو تاخیر کا اضافہ کرتے ہیں: کنکشن کھولنا اور بند کرنا، ڈیٹا کی درخواست کرنا، اور ڈیٹا بیس سے جڑنا۔ گراف سے پتہ چلتا ہے کہ ڈی این ایس کی درخواستیں، کھولنے اور بند کرنے کے کل وقت کا تقریباً 13 فیصد حصہ لیتا ہے۔

مفروضہ: پولنگ کا استعمال کرتے ہوئے کنکشن کو دوبارہ استعمال کرنے سے ایک ہی HTTP درخواست کا وقت کم ہونا چاہیے، جس سے زیادہ تھرو پٹ اور کم تاخیر کی اجازت ہو.

ایپلیکیشن ترتیب دینا - تجربہ

ہم سورس کوڈ کو اپ ڈیٹ کرتے ہیں، ہر درخواست کے لیے Postgresql سے کنکشن ہٹانے کی کوشش کریں۔ پہلا آپشن استعمال کرنا ہے۔ کنکشن پول درخواست کی سطح پر۔ اس تجربے میں ہم چلو اسے ترتیب دیں جانے کے لیے ایس کیو ایل ڈرائیور کا استعمال کرتے ہوئے کنکشن پولنگ:

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 درخواستیں فی سیکنڈ کے حساب سے ایپلیکیشن کو ڈیبگ کرنے کے نتائج جمع اور ڈسپلے کرتے ہیں:

اب بھی 6% وقت کنکشن قائم کرنے میں صرف ہوتا ہے۔ پول کو ترتیب دینے سے کارکردگی میں بہتری آئی ہے، لیکن آپ اب بھی دیکھ سکتے ہیں کہ ایپلیکیشن ڈیٹا بیس سے نئے کنکشن بنانے پر کام جاری رکھے ہوئے ہے۔

مفروضہ: کنکشنز، پول کی موجودگی کے باوجود، اب بھی گرائے جاتے ہیں اور صاف کیے جاتے ہیں، لہذا ایپلیکیشن کو انہیں دوبارہ ترتیب دینے کی ضرورت ہے۔ زیر التواء کنکشنز کی تعداد کو پول کے سائز پر سیٹ کرنے سے ایپلی کیشن کنکشن بنانے میں خرچ کرنے والے وقت کو کم سے کم کرکے تاخیر میں مدد کرے گی۔.

ایپلیکیشن ترتیب دینا - تجربہ

انسٹال کرنے کی کوشش کر رہا ہے۔ MaxIdleConns پول کے سائز کے برابر (بھی بیان کیا گیا ہے۔ یہاں):

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