Kama ilivyo machapisho mengi, kuna shida na huduma iliyosambazwa, tuite huduma hii Alvin. Wakati huu sikugundua shida mwenyewe, wavulana kutoka upande wa mteja walinijulisha.

Siku moja niliamshwa na barua pepe isiyoridhika kutokana na kuchelewa kwa muda mrefu na Alvin, ambayo tulipanga kuizindua siku za usoni. Hasa, mteja alipata hali ya kusubiri kwa asilimia 99 katika eneo la ms 50, zaidi ya bajeti yetu ya kusubiri. Hili lilikuwa jambo la kushangaza nilipojaribu huduma kwa upana, haswa kwenye latency, ambayo ni malalamiko ya kawaida.

Kabla sijamtia Alvin kwenye majaribio, nilifanya majaribio mengi na maswali 40k kwa sekunde (QPS), yote yakionyesha muda wa kusubiri wa chini ya 10ms. Nilikuwa tayari kutangaza kuwa sikubaliani na matokeo yao. Lakini nikiiangalia barua hiyo tena, niliona kitu kipya: Sikuwa nimejaribu haswa masharti waliyotaja, QPS yao ilikuwa chini sana kuliko yangu. Nilijaribu kwa 40k QPS, lakini ni 1k tu. Niliendesha jaribio lingine, wakati huu na QPS ya chini, ili tu kuwaridhisha.

Kwa kuwa ninablogi kuhusu hili, labda tayari umegundua kuwa nambari zao zilikuwa sawa. Nilijaribu mteja wangu wa kawaida mara kwa mara, na matokeo sawa: idadi ndogo ya maombi sio tu huongeza muda wa kusubiri, lakini huongeza idadi ya maombi na latency ya zaidi ya 10 ms. Kwa maneno mengine, ikiwa katika 40k QPS kuhusu maombi 50 kwa sekunde yalizidi 50 ms, basi kwa 1k QPS kulikuwa na maombi 100 juu ya 50 ms kila pili. Kitendawili!

Kupunguza utafutaji

Unapokabiliwa na tatizo la latency katika mfumo uliosambazwa na vipengele vingi, hatua ya kwanza ni kuunda orodha fupi ya watuhumiwa. Wacha tuchimbue kwa undani usanifu wa Alvin:

Sehemu nzuri ya kuanzia ni orodha ya mabadiliko ya I/O yaliyokamilishwa (simu za mtandao/utafutaji wa diski, n.k.). Wacha tujaribu kujua kuchelewesha ni wapi. Kando na I/O dhahiri na mteja, Alvin huchukua hatua ya ziada: anapata hifadhi ya data. Hata hivyo, hifadhi hii inafanya kazi katika kundi moja na Alvin, kwa hivyo muda wa kusubiri unapaswa kuwa mdogo kuliko wa mteja. Kwa hivyo, orodha ya watuhumiwa:

1. Simu ya mtandao kutoka kwa mteja kwenda kwa Alvin.
2. Simu ya mtandao kutoka kwa Alvin hadi kwenye duka la data.
3. Tafuta kwenye diski kwenye hifadhi ya data.
4. Simu ya mtandao kutoka kwa ghala la data kwenda kwa Alvin.
5. Simu ya mtandao kutoka kwa Alvin hadi kwa mteja.

Hebu jaribu kuvuka baadhi ya pointi.

Hifadhi ya data haina uhusiano wowote nayo

Jambo la kwanza nililofanya ni kubadilisha Alvin kuwa seva ya ping-ping ambayo haishughulikii maombi. Inapopokea ombi, hurejesha jibu tupu. Ikiwa latency itapungua, basi mdudu katika utekelezaji wa ghala la Alvin au data sio kitu kisichojulikana. Katika jaribio la kwanza tunapata grafu ifuatayo:

Kama unaweza kuona, hakuna uboreshaji wakati wa kutumia seva ya ping-ping. Hii inamaanisha kuwa ghala la data haliongezi muda wa kusubiri, na orodha ya washukiwa imekatwa katikati:

1. Simu ya mtandao kutoka kwa mteja kwenda kwa Alvin.
2. Simu ya mtandao kutoka kwa Alvin hadi kwa mteja.

Kubwa! Orodha inapungua haraka. Nilidhani nilikuwa karibu kujua sababu.

gRPC

Sasa ni wakati wa kukutambulisha kwa mchezaji mpya: gRPC. Hii ni maktaba ya programu huria kutoka kwa Google kwa mawasiliano ya ndani ya mchakato RPC. Ingawa gRPC iliyoboreshwa vizuri na inatumika sana, hii ilikuwa mara yangu ya kwanza kuitumia kwenye mfumo wa ukubwa huu na nilitarajia utekelezaji wangu kuwa mdogo - kusema mdogo.

upatikanaji gRPC kwenye stack ilitoa swali jipya: labda ni utekelezaji wangu au mimi mwenyewe gRPC kusababisha tatizo la kutochelewa? Kuongeza mtuhumiwa mpya kwenye orodha:

1. Mteja anaita maktaba gRPC
2. maktaba gRPC hufanya simu ya mtandao kwa maktaba kwenye mteja gRPC kwenye seva
3. maktaba gRPC mawasiliano Alvin (hakuna operesheni ikiwa seva ya ping-pong)

Ili kukupa wazo la jinsi nambari inavyoonekana, utekelezaji wa mteja/Alvin sio tofauti sana na zile za seva ya mteja. mifano ya async.

Kumbuka: Orodha iliyo hapo juu imerahisishwa kidogo kwa sababu gRPC inafanya uwezekano wa kutumia modeli yako (kiolezo?) ya uzi, ambayo safu ya utekelezaji imeunganishwa. gRPC na utekelezaji wa mtumiaji. Kwa ajili ya unyenyekevu, tutashikamana na mfano huu.

Kuweka wasifu kutarekebisha kila kitu

Baada ya kupita maduka ya data, nilidhani nilikuwa karibu kumaliza: "Sasa ni rahisi! Wacha tutumie wasifu na tujue ni wapi ucheleweshaji unatokea." I shabiki mkubwa wa uwekaji wasifu kwa usahihi, kwa sababu CPU ni haraka sana na mara nyingi sio kizuizi. Ucheleweshaji mwingi hutokea wakati kichakataji lazima kisimamishe usindikaji ili kufanya kitu kingine. Uwekaji wasifu sahihi wa CPU hufanya hivyo tu: hurekodi kila kitu kwa usahihi swichi za muktadha na kuweka wazi ambapo ucheleweshaji hutokea.

Nilichukua wasifu nne: na QPS ya juu (chini ya latency) na seva ya ping-pong yenye QPS ya chini (high latency), wote kwa upande wa mteja na upande wa seva. Na ikiwa tu, nilichukua pia wasifu wa processor ya sampuli. Wakati wa kulinganisha wasifu, mimi hutafuta rundo la simu lisilo la kawaida. Kwa mfano, kwa upande mbaya na latency ya juu kuna swichi nyingi zaidi za muktadha (mara 10 au zaidi). Lakini katika kesi yangu, idadi ya swichi za muktadha ilikuwa karibu sawa. Kwa mshtuko wangu, hakukuwa na kitu cha maana hapo.

Utatuzi wa Ziada

Nilikuwa katika kukata tamaa. Sikujua ni zana gani nyingine ningeweza kutumia, na mpango wangu uliofuata ulikuwa kimsingi kurudia majaribio kwa tofauti tofauti badala ya kugundua shida kwa uwazi.

Je! Ikiwa

Tangu mwanzo kabisa, nilikuwa na wasiwasi kuhusu latency maalum ya 50ms. Huu ni wakati mkubwa sana. Niliamua kwamba nitakata vipande kutoka kwa nambari hadi niweze kujua ni sehemu gani inayosababisha kosa hili. Kisha ikaja jaribio ambalo lilifanya kazi.

Kama kawaida, kwa mtazamo wa nyuma inaonekana kwamba kila kitu kilikuwa dhahiri. Niliweka mteja kwenye mashine sawa na Alvin - na kutuma ombi kwa localhost. Na ongezeko la latency limekwenda!

Hitilafu fulani kwenye mtandao.

Kujifunza ujuzi wa mhandisi wa mtandao

Lazima nikubali: ujuzi wangu wa teknolojia za mtandao ni mbaya, hasa kwa kuzingatia ukweli kwamba mimi hufanya kazi nao kila siku. Lakini mtandao ulikuwa mshukiwa mkuu, na nilihitaji kujifunza jinsi ya kuisuluhisha.

Kwa bahati nzuri, Mtandao unapenda wale wanaotaka kujifunza. Mchanganyiko wa ping na tracert ulionekana kama mwanzo mzuri wa kutatua matatizo ya usafiri wa mtandao.

Kwanza, nilizindua PsPing kwa bandari ya TCP ya Alvin. Nilitumia mipangilio chaguo-msingi - hakuna kitu maalum. Kati ya pings zaidi ya elfu moja, hakuna iliyozidi ms 10, isipokuwa ya kwanza ya kuongeza joto. Hii ni kinyume na ongezeko lililoonekana la latency ya 50 ms katika percentile ya 99: huko, kwa kila maombi 100, tunapaswa kuwa tumeona kuhusu ombi moja kwa muda wa 50 ms.

Kisha nikajaribu mfuatiliaji: Kunaweza kuwa na tatizo katika mojawapo ya vifundo kando ya njia kati ya Alvin na mteja. Lakini mfuatiliaji naye alirudi mikono mitupu.

Kwa hivyo haikuwa nambari yangu, utekelezaji wa gRPC, au mtandao ambao ulikuwa unasababisha kucheleweshwa. Nilianza kuwa na wasiwasi kwamba sitawahi kuelewa hili.

Sasa tuko kwenye OS gani

gRPC inatumika sana kwenye Linux, lakini ya kigeni kwenye Windows. Niliamua kujaribu jaribio, ambalo lilifanya kazi: Niliunda mashine ya Linux, iliyokusanya Alvin kwa ajili ya Linux, na kuipeleka.

Na hiki ndicho kilichotokea: seva ya Linux ping-pong haikuwa na ucheleweshaji sawa na seva pangishi ya Windows, ingawa chanzo cha data hakikuwa tofauti. Inabadilika kuwa shida iko katika utekelezaji wa gRPC kwa Windows.

Algorithm ya Nagle

Wakati huu wote nilifikiri kwamba ninakosa bendera gRPC. Sasa ninaelewa ni nini hasa gRPC Bendera ya Windows haipo. Nilipata maktaba ya ndani ya RPC ambayo nilikuwa na uhakika kwamba ingefanya kazi vizuri kwa bendera zote zilizowekwa Winsock. Kisha nikaongeza bendera hizi zote kwa gRPC na kupeleka Alvin kwenye Windows, kwenye seva ya ping-pong ya Windows!

Karibu Imekamilika: Nilianza kuondoa bendera zilizoongezwa moja kwa wakati hadi hali ya kumbukumbu irudi ili niweze kubainisha sababu. Ilikuwa ni sifa mbaya TCP_NODELAY, swichi ya algorithm ya Nagle.

Algorithm ya Nagle majaribio ya kupunguza idadi ya pakiti zilizotumwa kwenye mtandao kwa kuchelewesha utumaji wa ujumbe hadi saizi ya pakiti izidi idadi fulani ya baiti. Ingawa hii inaweza kuwa nzuri kwa mtumiaji wa kawaida, ni hatari kwa seva za wakati halisi kwani OS itachelewesha baadhi ya ujumbe, na kusababisha kuchelewa kwa QPS ya chini. U gRPC bendera hii iliwekwa katika utekelezaji wa Linux kwa soketi za TCP, lakini sio kwenye Windows. Mimi ni huyu iliyosahihishwa.

Hitimisho

Muda wa kusubiri wa juu katika QPS ya chini ulisababishwa na uboreshaji wa mfumo wa uendeshaji. Kwa kutazama nyuma, uwekaji wasifu haukugundua muda wa kusubiri kwa sababu ulifanyika katika hali ya kernel badala ya in hali ya mtumiaji. Sijui ikiwa algorithm ya Nagle inaweza kuzingatiwa kupitia kukamata kwa ETW, lakini itakuwa ya kufurahisha.

Kuhusu jaribio la mwenyeji, labda halikugusa msimbo halisi wa mtandao na kanuni ya Nagle haikufanya kazi, kwa hivyo masuala ya kusubiri yalitoweka mteja alipomfikia Alvin kupitia localhost.

Wakati mwingine utakapoona ongezeko la muda huku idadi ya maombi kwa sekunde ikipungua, kanuni ya Nagle inapaswa kuwa kwenye orodha yako ya washukiwa!

Chanzo: mapenzi.com