لکه په ډیری پوسټونهد ویشل شوي خدمت سره ستونزه ده، راځئ چې دې خدمت ته الوین ووایو. دا ځل ما پخپله ستونزه ونه موندله، د پیرودونکي اړخ هلکانو ما ته خبر ورکړ.

یوه ورځ زه د الویین سره د اوږد ځنډ له امله ناراضه بریښنالیک ته راغلم، کوم چې موږ په نږدې راتلونکي کې د پیل کولو پلان درلود. په ځانګړې توګه، پیرودونکي د 99 ms په سیمه کې د 50 فیصده ځنډ تجربه کړې، زموږ د ځنډنۍ بودیجې څخه ښه. دا د حیرانتیا خبره وه ځکه چې ما خدمت په پراخه کچه ازموینه کړې ، په ځانګړي توګه په ځنډ کې ، کوم چې یو عام شکایت دی.

مخکې لدې چې زه ایلوین ازموینې ته واچوم ، ما په هره ثانیه کې د 40k پوښتنو سره ډیری تجربې ترسره کړې (QPS) ، ټول د 10ms څخه کم ځنډ ښیې. زه چمتو وم چې اعلان وکړم چې زه د دوی له پایلو سره موافق نه وم. مګر لیک ته د بل نظر په اخیستلو سره، ما یو څه نوی ولید: ما په سمه توګه هغه شرایط ندي ازمولي چې دوی یې یادونه کړې، د دوی QPS زما په پرتله خورا ټیټ و. ما په 40k QPS کې ازموینه وکړه ، مګر دوی یوازې په 1k کې. ما بله تجربه وکړه، دا ځل د ټیټ QPS سره، یوازې د دوی د خوښولو لپاره.

له هغه وخته چې زه د دې په اړه بلاګ کوم، تاسو شاید دمخه معلومه کړې چې د دوی شمیرې سمې وې. ما خپل مجازی پیرودونکی په وار وار ازمویلی، د ورته پایلې سره: د غوښتنو لږ شمیر نه یوازې ځنډ زیاتوي، مګر د 10 ms څخه ډیر ځنډ سره د غوښتنو شمیر ډیروي. په بل عبارت، که په 40k QPS کې په هره ثانیه کې شاوخوا 50 غوښتنې د 50 ms څخه زیاتې وي، نو په 1k QPS کې په هره ثانیه کې د 100 ms څخه پورته 50 غوښتنې وې. پاراډکس!

د لټون لنډول

کله چې د ډیری برخو سره توزیع شوي سیسټم کې د ځنډ ستونزې سره مخ وي ، لومړی ګام د شکمنو لنډ لیست رامینځته کول دي. راځئ چې د الوین معمارۍ ته یو څه ژور وګورو:

یو ښه پیل ټکی د بشپړ شوي I/O لیږدونو لیست دی (د شبکې تلیفونونه/ډیسک لټونونه، او نور). راځئ هڅه وکړو چې معلومه کړو چې ځنډ چیرته دی. د پیرودونکي سره د واضح I/O سربیره، الون یو اضافي ګام اخلي: هغه د ډیټا ذخیره ته لاسرسی لري. په هرصورت، دا ذخیره د الوین په څیر په ورته کلستر کې کار کوي، نو د دې لپاره ځنډ باید د پیرودونکي په پرتله لږ وي. نو، د شکمنو کسانو لیست:

1. له پیرودونکي څخه الون ته د شبکې زنګ.
2. د الوین څخه ډیټا پلورنځي ته د شبکې زنګ.
3. د ډیټا ذخیره کې په ډیسک کې لټون وکړئ.
4. د ډیټا ګودام څخه ایلوین ته د شبکې زنګ.
5. له الوین څخه پیرودونکي ته د شبکې زنګ.

راځئ هڅه وکړو چې ځینې ټکي تیر کړو.

د معلوماتو ذخیره کولو سره هیڅ تړاو نلري

لومړی شی چې ما وکړل ایلوین د ping-ping سرور ته بدل کړ چې غوښتنې نه پروسس کوي. کله چې دا غوښتنه ترلاسه کړي، دا یو خالي ځواب بیرته راولي. که ځنډ راټیټ شي ، نو بیا د الون یا ډیټا ګودام پلي کولو کې بګ هیڅ نه اوریدل کیږي. په لومړۍ تجربه کې موږ لاندې ګراف ترلاسه کوو:

لکه څنګه چې تاسو لیدلی شئ، د ping-ping سرور کارولو په وخت کې هیڅ پرمختګ شتون نلري. دا پدې مانا ده چې د معلوماتو ګودام ځنډ نه زیاتوي، او د شکمنو لیست نیمایي کې پرې شوی:

1. له پیرودونکي څخه الون ته د شبکې زنګ.
2. له الوین څخه پیرودونکي ته د شبکې زنګ.

غوره! لیست په چټکۍ سره کمیږي. ما فکر کاوه چې ما تقریبا دلیل موندلی دی.

gRPC

اوس هغه وخت دی چې تاسو یو نوی لوبغاړی معرفي کړئ: gRPC. دا د پروسې دننه اړیکو لپاره د ګوګل څخه د خلاصې سرچینې کتابتون دی RPC... که څه هم gRPC ښه اصلاح شوی او په پراخه کچه کارول شوی، دا زما لومړی ځل و چې د دې اندازې په سیسټم کې یې کارولی و او ما تمه درلوده چې زما پلي کول به تر ټولو غوره وي - لږترلږه ووایاست.

شتون gRPC په سټیک کې یوې نوې پوښتنې ته وده ورکړه: شاید دا زما پلي کول وي یا زه gRPC د ځنډ ستونزه رامینځته کوي؟ په لیست کې د نوي شکمن اضافه کول:

1. پیرودونکي کتابتون ته زنګ ووهي gRPC
2. کړی gRPC د پیرودونکي په کتابتون کې د شبکې زنګ وهي gRPC په سرور کې
3. کړی gRPC د ایلوین سره اړیکه (د پینګ پونګ سرور په صورت کې هیڅ عملیات نشته)

د دې لپاره چې تاسو ته یو نظر درکړو چې کوډ څه ډول ښکاري، زما د مراجعینو/الوین تطبیق د مراجعینو سرور څخه ډیر توپیر نلري async بېلګې.

یادونه: پورته لیست یو څه ساده دی ځکه چې gRPC دا ممکنه کوي چې ستاسو خپل (کینډۍ؟) تارینګ ماډل وکاروئ، په کوم کې چې د اجرا کولو سټیک یو بل سره تړلی وي gRPC او د کاروونکي تطبیق. د سادگي لپاره، موږ به دې ماډل ته پاته شو.

پروفایل کول به هرڅه سم کړي

د ډیټا پلورنځیو څخه تیریدو سره ، ما فکر کاوه چې ما تقریبا بشپړ شوی و: "اوس دا اسانه ده! راځئ چې پروفایل پلي کړو او معلومه کړو چې ځنډ چیرته پیښیږي. زه د دقیق پروفایل کولو لوی پرستار، ځکه چې CPUs خورا ګړندي دي او ډیری وختونه خنډ نه وي. ډیری ځنډونه واقع کیږي کله چې پروسیسر باید د بل څه کولو لپاره پروسس بند کړي. د CPU دقیق پروفایل کول یوازې دا کوي: دا په سمه توګه هرڅه ثبتوي د شرایطو بدلول او دا روښانه کوي چې چیرې ځنډ واقع کیږي.

ما څلور پروفایلونه اخیستي: د لوړ QPS سره (ټیټ ځنډ) او د پینګ پونګ سرور سره د ټیټ QPS (لوړ ځنډ) سره ، دواړه د پیرودونکي اړخ او سرور اړخ کې. او یوازې په قضیه کې، ما د نمونې پروسیسر پروفایل هم واخیست. کله چې د پروفایلونو پرتله کول، زه معمولا د غیر معمولي کال سټیک په لټه کې یم. د مثال په توګه ، د لوړې ځنډ سره په خراب اړخ کې ډیری نور شرایط سویچونه شتون لري (10 ځله یا ډیر). مګر زما په قضیه کې ، د شرایطو سویچونو شمیر نږدې ورته و. زما په ویره کې، هلته هیڅ مهم نه و.

اضافي Debugging

زه نا امیده وم. زه نه پوهیدم چې کوم نور وسیلې چې زه یې کارولی شم، او زما راتلونکی پلان په اصل کې دا و چې تجربې د مختلف توپیرونو سره تکرار کړم نه دا چې ستونزه په واضح ډول تشخیص کړم.

څه که

له پیل څخه، زه د ځانګړي 50ms ځنډ په اړه اندیښمن وم. دا یو ډیر لوی وخت دی. ما پریکړه وکړه چې زه به د کوډ څخه ټوټه ټوټه کړم تر هغه چې زه په سمه توګه معلومه کړم چې کومه برخه د دې تېروتنې لامل شوې. بیا یوه تجربه راغله چې کار یې وکړ.

د معمول په څیر، په پټه توګه داسې ښکاري چې هر څه څرګند وو. ما پیرودونکي په ورته ماشین کې د ایلوین په څیر ځای په ځای کړل - او غوښتنه یې واستوله localhost. او د ځنډ زیاتوالی له منځه تللی!

په شبکه کې یو څه غلط وو.

د شبکې انجنیر مهارتونه زده کړئ

زه باید اعتراف وکړم: د شبکې ټیکنالوژیو زما پوهه خورا خطرناکه ده، په ځانګړې توګه د دې حقیقت په پام کې نیولو سره چې زه هره ورځ ورسره کار کوم. مګر شبکه اصلي شکمن و، او ما اړتیا درلوده چې زده کړي چې دا څنګه ډیبګ کړي.

خوشبختانه، انټرنیټ هغه کسان خوښوي چې غواړي زده کړي. د پینګ او ټریسرټ ترکیب داسې بریښي چې د شبکې ټرانسپورټ ستونزو ډیبګ کولو لپاره کافي ښه پیل وي.

لومړی، ما پیل کړ PsPing د ایلوین TCP بندر ته. ما د ډیفالټ ترتیبات کارولي - هیڅ ځانګړي ندي. له زرو څخه ډیرو پینګونو کې، هیڅ یو له 10 ms څخه ډیر نه و، د ګرم کولو لپاره د لومړي استثنا سره. دا په 50 فیصده کې د 99 ms په ځنډ کې د لیدل شوي زیاتوالی سره مخالف دی: هلته، د هر 100 غوښتنو لپاره، موږ باید د 50 ms ځنډ سره شاوخوا یوه غوښتنه لیدلې وای.

بیا ما هڅه وکړه ټریټ: کیدای شي د الوین او مراجعینو ترمنځ د لارې په اوږدو کې په یوه نوډ کې ستونزه وي. خو ټرسر هم خالي لاس راستون شو.

نو دا زما کوډ، د gRPC تطبیق، یا هغه شبکه نه وه چې د ځنډ لامل و. ما اندیښنه پیل کړه چې زه به هیڅکله پدې پوه نه شم.

اوس موږ په کوم OS کې یو

gRPC په پراخه کچه په لینوکس کې کارول کیږي، مګر په وینډوز کې خارجي. ما پریکړه وکړه چې یوه تجربه هڅه وکړم، کوم چې کار وکړ: ما د لینوکس مجازی ماشین جوړ کړ، د لینوکس لپاره الون تالیف کړ، او ځای پر ځای یې کړ.

او دلته هغه څه دي چې پیښ شوي: د لینکس پینګ پونګ سرور د ورته وینډوز کوربه په څیر ورته ځنډ نه درلود، که څه هم د معلوماتو سرچینه توپیر نه درلود. دا معلومه شوه چې ستونزه د وینډوز لپاره د gRPC تطبیق کې ده.

د ناګل الګوریتم

دا ټول وخت ما فکر کاوه چې زه یو بیرغ له لاسه ورکوم gRPC. اوس زه پوهیږم چې دا واقعیا څه ده gRPC د وینډوز بیرغ ورک دی. ما یو داخلي RPC کتابتون وموند چې زه ډاډه وم چې د ټولو بیرغونو لپاره به ښه کار وکړي ونساک. بیا ما دا ټول بیرغونه gRPC ته اضافه کړل او ایلوین په وینډوز کې ځای په ځای کړ ، په پیچ شوي وینډوز پینګ پانګ سرور کې!

تقریبا بشپړ شوی: ما په یو وخت کې یوځل اضافه شوي بیرغونه لرې کول پیل کړل تر هغه چې ریګریشن بیرته راشي نو زه کولی شم علت په ګوته کړم. دا بدنامه وه TCP_NODELAY, Nagle د الګوریتم سویچ.

د ناګل الګوریتم د پیغامونو لیږد ځنډولو سره په شبکه کې د لیږل شوي کڅوړو شمیر کمولو هڅه کوي تر هغه چې د پیکټ اندازه د یو ټاکلي شمیر بایټ څخه زیاته نشي. پداسې حال کې چې دا ممکن د اوسط کارونکي لپاره ښه وي ، دا د ریښتیني وخت سرورونو لپاره ویجاړونکی دی ځکه چې OS به ځینې پیغامونه وځنډوي ، د ټیټ QPS کې ځنډ لامل کیږي. یو gRPC دا بیرغ د TCP ساکټونو لپاره د لینکس تطبیق کې تنظیم شوی و، مګر په وینډوز کې نه. زه دا یم اصلاح شوی.

پایلې

په ټیټ QPS کې لوړ ځنډ د OS اصلاح کولو له امله رامینځته شوی. په شاتګ کې ، پروفایل کول ځنډ ندی موندلی ځکه چې دا د کرنل په حالت کې نه بلکه په کرنل حالت کې ترسره شوی د کارونکي حالت. زه نه پوهیږم چې ایا د ناګل الګوریتم د ETW نیولو له لارې لیدل کیدی شي، مګر دا به په زړه پورې وي.

لکه څنګه چې د لوکل هوسټ تجربې لپاره ، دا شاید د ریښتیني شبکې کوډ ته لاس ورنکړ او د ناګل الګوریتم نه چلیږي ، نو د ځنډ مسلې له مینځه لاړې کله چې پیرودونکي د لوکل هوسټ له لارې ایلوین ته ورسید.

بل ځل چې تاسو د ځنډ زیاتوالی وګورئ ځکه چې په ثانیه کې د غوښتنو شمیر کمیږي ، د ناګل الګوریتم باید ستاسو د شکمنو لیست کې وي!

سرچینه: www.habr.com