Xuddi shunday eng ko'p postlar, taqsimlangan xizmatda muammo bor, keling, bu xizmatni Alvin deb ataymiz. Bu safar men muammoni o'zim aniqlamadim, mijoz tomonidagi yigitlar menga xabar berishdi.

Bir kuni biz yaqin kelajakda ishga tushirishni rejalashtirgan Alvin bilan uzoq kechikishlar tufayli norozi elektron pochta xabaridan uyg'onib ketdim. Xususan, mijoz 99 milodiy mintaqada 50 foizli kechikishni boshdan kechirdi, bu bizning kechikish byudjetimizdan ancha yuqori. Bu hayratlanarli bo'ldi, chunki men xizmatni keng ko'lamda sinab ko'rdim, ayniqsa kechikish, bu odatiy shikoyat.

Alvinni sinovdan o'tkazishdan oldin men sekundiga 40 ming so'rov (QPS) bilan ko'plab tajribalar o'tkazdim, ularning barchasi kechikish vaqti 10 ms dan kam edi. Men ularning natijalariga rozi emasligimni e'lon qilishga tayyor edim. Ammo xatga yana bir nazar tashlab, men yangi narsani payqadim: men ular aytgan shartlarni aniq sinab ko‘rmagan edim, ularning QPS darajasi menikidan ancha past edi. Men 40k QPSda sinab ko'rdim, lekin ular faqat 1kda. Men ularni tinchlantirish uchun bu safar pastroq QPS bilan yana bir tajriba o'tkazdim.

Men bu haqda blog yuritayotganim uchun siz ularning soni to'g'ri ekanligini allaqachon tushungan bo'lsangiz kerak. Men virtual mijozimni qayta-qayta sinab ko‘rdim, xuddi shunday natija: so‘rovlar sonining kamligi nafaqat kechikish vaqtini oshiribgina qolmay, balki kechikish vaqti 10 ms dan ortiq bo‘lgan so‘rovlar sonini ham oshiradi. Boshqacha qilib aytganda, agar 40k QPSda soniyada 50 ga yaqin so'rov 50 ms dan oshsa, 1k QPSda har soniyada 100 ms dan ortiq 50 ta so'rov bo'lgan. Paradoks!

Qidiruvni qisqartirish

Ko'p komponentli taqsimlangan tizimda kechikish muammosiga duch kelganda, birinchi qadam shubhali shaxslarning qisqa ro'yxatini yaratishdir. Keling, Alvin arxitekturasini biroz chuqurroq o'rganamiz:

Yaxshi boshlanish nuqtasi - bu tugallangan kiritish-chiqarish o'tishlari ro'yxati (tarmoq qo'ng'iroqlari/diskni qidirish va h.k.). Keling, kechikish qayerda ekanligini aniqlashga harakat qilaylik. Mijoz bilan aniq kiritish-chiqarishdan tashqari, Alvin qo'shimcha qadam tashlaydi: u ma'lumotlar do'koniga kiradi. Biroq, bu saqlash Alvin bilan bir xil klasterda ishlaydi, shuning uchun u erda kechikish mijozga qaraganda kamroq bo'lishi kerak. Shunday qilib, gumondorlar ro'yxati:

1. Mijozdan Alvinga tarmoq qo'ng'irog'i.
2. Alvindan ma'lumotlar do'koniga tarmoq qo'ng'irog'i.
3. Ma'lumotlar do'konida diskda qidiring.
4. Ma'lumotlar omboridan Alvinga tarmoq qo'ng'irog'i.
5. Alvindan mijozga tarmoq qo'ng'irog'i.

Keling, ba'zi fikrlarni kesib o'tishga harakat qilaylik.

Ma'lumotlarni saqlash bu bilan hech qanday aloqasi yo'q

Men qilgan birinchi narsa Alvinni so'rovlarni qayta ishlamaydigan ping-ping serveriga aylantirish edi. So'rovni qabul qilganda, u bo'sh javob qaytaradi. Agar kechikish kamaysa, Alvin yoki ma'lumotlar omborini amalga oshirishdagi xatolik eshitilmagan narsa emas. Birinchi tajribada biz quyidagi grafikni olamiz:

Ko'rib turganingizdek, ping-ping serveridan foydalanishda hech qanday yaxshilanish yo'q. Bu shuni anglatadiki, ma'lumotlar ombori kechikishni oshirmaydi va gumonlanuvchilar ro'yxati yarmiga qisqartiriladi:

1. Mijozdan Alvinga tarmoq qo'ng'irog'i.
2. Alvindan mijozga tarmoq qo'ng'irog'i.

Ajoyib! Ro'yxat tezda qisqarmoqda. Sababini deyarli tushundim deb o'yladim.

gRPC

Endi sizni yangi o'yinchi bilan tanishtirish vaqti keldi: gRPC. Bu jarayon davomida muloqot qilish uchun Google’dan ochiq manbali kutubxona CPR. Garchi gRPC yaxshi optimallashtirilgan va keng qo'llanilgan, men uni bunday o'lchamdagi tizimda birinchi marta ishlatganman va men amalga oshirishim suboptimal bo'lishini kutgan edim - eng kamida.

imkoniyat gRPC stekda yangi savol tug'ildi: ehtimol bu mening amalga oshirishim yoki o'zim gRPC kechikish muammosiga sabab bo'ladimi? Ro'yxatga yangi gumondorni qo'shish:

1. Mijoz kutubxonaga qo'ng'iroq qiladi gRPC
2. kutubxona gRPC mijozdagi kutubxonaga tarmoq qo'ng'irog'ini amalga oshiradi gRPC serverda
3. kutubxona gRPC kontaktlar Alvin (ping-pong serverida ishlamaydi)

Kod qanday ko'rinishi haqida tasavvurga ega bo'lish uchun mening mijozim/Alvin ilovasi mijoz-serverdan unchalik farq qilmaydi. asinx misollar.

Eslatma: Yuqoridagi ro'yxat biroz soddalashtirilgan, chunki gRPC o'zingizning (shablon?) o'tkazgich modelingizdan foydalanishga imkon beradi, unda ijro etuvchi stek bir-biriga bog'langan. gRPC va foydalanuvchini amalga oshirish. Oddiylik uchun biz ushbu modelga yopishib olamiz.

Profillash hamma narsani hal qiladi

Ma'lumotlar do'konlarini kesib o'tib, men deyarli tugatdim deb o'yladim: “Endi bu oson! Keling, profilni qo'llaymiz va kechikish qayerda sodir bo'lishini bilib olaylik." I aniq profil yaratishning katta muxlisi, chunki protsessorlar juda tez va ko'pincha qiyinchilik tug'dirmaydi. Aksariyat kechikishlar protsessor boshqa biror narsa qilish uchun ishlov berishni to'xtatishi kerak bo'lganda sodir bo'ladi. To'g'ri CPU profili buni amalga oshiradi: u hamma narsani aniq yozib oladi kontekst kalitlari va kechikishlar qaerda sodir bo'lishini aniq ko'rsatadi.

Men to'rtta profilni oldim: yuqori QPS (past kechikish) va past QPS (yuqori kechikish) bilan ping-pong serveri bilan mijoz tomonida ham, server tomonida ham. Va har holda, men protsessor profilining namunasini ham oldim. Profillarni solishtirganda, men odatda anomal qo'ng'iroqlar to'plamini qidiraman. Masalan, yuqori kechikishning yomon tomonida yana ko'p kontekstli kalitlar mavjud (10 marta yoki undan ko'p). Lekin mening vaziyatimda kontekstli kalitlarning soni deyarli bir xil edi. Mening dahshatim shundaki, u erda muhim narsa yo'q edi.

Qo'shimcha disk raskadrovka

Men umidsiz edim. Men boshqa qanday vositalardan foydalanishim mumkinligini bilmasdim va mening keyingi rejam muammoni aniq tashxislashdan ko'ra, tajribalarni turli xil o'zgarishlar bilan takrorlash edi.

Agar .. bo'lsa nima bo'ladi

Eng boshidanoq men 50 ms kechikish haqida tashvishlanardim. Bu juda katta vaqt. Qaysi qism bu xatoga sabab bo'lganini aniqlay olmagunimcha, koddan bo'laklarni kesib tashlashga qaror qildim. Keyin ishlagan tajriba keldi.

Odatdagidek, orqaga qarab, hamma narsa ayon bo'lganga o'xshaydi. Men mijozni Alvin bilan bir xil mashinaga joylashtirdim va unga so'rov yubordim localhost. Va kechikishning o'sishi yo'qoldi!

Tarmoq bilan nimadir noto‘g‘ri ketdi.

Tarmoq muhandisi ko'nikmalarini o'rganish

Tan olaman: tarmoq texnologiyalari haqidagi bilimim dahshatli, ayniqsa men ular bilan har kuni ishlayotganimni hisobga olsak. Ammo tarmoq asosiy shubhali edi va men uni qanday tuzatishni o'rganishim kerak edi.

Yaxshiyamki, Internet o'rganishni xohlaydiganlarni yaxshi ko'radi. Ping va tracert kombinatsiyasi tarmoqni tashish muammolarini tuzatish uchun etarlicha yaxshi boshlanish kabi ko'rindi.

Birinchidan, men ishga tushirdim PsPing Alvinning TCP portiga. Men standart sozlamalardan foydalandim - hech qanday maxsus narsa yo'q. Mingdan ortiq pinglarning hech biri 10 ms dan oshmadi, isinish uchun birinchisidan tashqari. Bu 50-persentilda kuzatilgan kechikishning 99 ms ga oshishiga ziddir: u erda har 100 so'rov uchun biz 50 ms kechikish bilan bitta so'rovni ko'rishimiz kerak edi.

Keyin harakat qildim kuzatuvchi: Alvin va mijoz o'rtasidagi marshrutdagi tugunlardan birida muammo bo'lishi mumkin. Ammo izdosh ham quruq qo‘l bilan qaytdi.

Demak, kechikishga sabab mening kodim, gRPC ilovasi yoki tarmoq emas edi. Men buni hech qachon tushunolmayman deb xavotirlana boshladim.

Endi biz qaysi operatsion tizimdamiz

gRPC Linuxda keng qo'llaniladi, lekin Windowsda ekzotik. Men tajriba o'tkazishga qaror qildim, bu ish berdi: men Linux virtual mashinasini yaratdim, Linux uchun Alvinni kompilyatsiya qildim va uni ishga tushirdim.

Va shunday bo'ldi: Linux ping-pong serveri shunga o'xshash Windows xosti bilan bir xil kechikishlarga ega emas edi, garchi ma'lumotlar manbai boshqacha bo'lmasa ham. Ma'lum bo'lishicha, muammo Windows uchun gRPC ilovasida.

Nagle algoritmi

Shu vaqt ichida men bayroqni sog'indim deb o'yladim gRPC. Endi men aslida nima ekanligini tushunaman gRPC Windows bayrog'i yo'q. Men barcha bayroqlar uchun yaxshi ishlashiga ishongan ichki RPC kutubxonasini topdim Winsock. Keyin men ushbu bayroqlarning barchasini gRPC-ga qo'shdim va Alvinni Windows-da, yamalgan Windows ping-pong serverida joylashtirdim!

Deyarli Bajarildi: Men qo'shilgan bayroqlarni birma-bir olib tashlashni boshladim, shunda men regressiya qaytguncha sababni aniqlay olaman. Bu sharmandali edi TCP_NODELAY, Nagle algoritmi kaliti.

Nagle algoritmi paket hajmi ma'lum bir bayt sonidan oshib ketguncha xabarlarni uzatishni kechiktirish orqali tarmoq orqali yuborilgan paketlar sonini kamaytirishga harakat qiladi. Bu oddiy foydalanuvchi uchun yoqimli bo'lishi mumkin bo'lsa-da, real vaqt serverlari uchun bu halokatli, chunki OS ba'zi xabarlarni kechiktirib, past QPSda kechikishlarga olib keladi. U gRPC bu bayroq TCP soketlari uchun Linux ilovasida o'rnatilgan, lekin Windowsda emas. Men buman tuzatilgan.

xulosa

Past QPSda yuqori kechikish OS optimallashtirishdan kelib chiqqan. Orqaga nazar tashlaydigan bo'lsak, profil yaratish kechikishni aniqlamadi, chunki u yadro rejimida emas, balki yadro rejimida amalga oshirilgan foydalanuvchi rejimi. Nagle algoritmini ETW tasvirlari orqali kuzatish mumkinligini bilmayman, lekin bu qiziq bo'lardi.

Localhost tajribasiga kelsak, ehtimol u haqiqiy tarmoq kodiga tegmagan va Nagle algoritmi ishlamagan, shuning uchun mijoz localhost orqali Alvinga yetib borganida kechikish bilan bogʻliq muammolar yoʻqolib ketdi.

Keyingi safar sekundiga so'rovlar soni kamayishi bilan kechikishning oshishini ko'rsangiz, Nagle algoritmi shubhalilar ro'yxatida bo'lishi kerak!

Manba: www.habr.com