Wekî ku di piraniya postan, di servîsa belavkirî de pirsgirêkek heye, em ji vê servîsê re bibêjin Alvin. Vê carê min bi xwe pirsgirêk kifş nekir, xortên ji aliyê muwekîlê ve ez agahdar kirim.

Rojekê ez bi e-nameyek nerazî hişyar bûm ji ber derengiyên dirêj ên bi Alvin re, ku me plan kir ku di demek nêzîk de dest pê bikin. Bi taybetî, xerîdar derengiya ji sedî 99-an li herêma 50 ms, ji budceya derengiya me pir jortir e. Ev ecêb bû ji ber ku min karûbar bi berfirehî ceriband, nemaze li ser derengiyê, ku gilîyek hevpar e.

Berî ku ez Alvin têxim ceribandinê, min gelek ceribandin li ser 40k pirs di çirkeyê de (QPS) meşandin, hemî derengiya ji 10ms kêmtir nîşan didin. Ez amade bûm ku ragihînim ku ez bi encamên wan re ne razî me. Lê carek din li nameyê nihêrî, min tiştek nû dît: Min şert û mercên ku wan behs kiribûn tam ceribandiye, QPS-ya wan ji ya min pir kêmtir bû. Min li 40k QPS ceriband, lê ew tenê li 1k. Min ceribandinek din kir, vê carê bi QPS-ya jêrîn, tenê ji bo ku wan razî bikim.

Ji ber ku ez li ser vê blogê dinivîsim, belkî we berê jî fêm kir ku hejmarên wan rast bûn. Min muwekîlê xweya virtual dîsa û dîsa bi heman encamê ceriband: hejmarek kêm daxwaz ne tenê derengiyê zêde dike, lê hejmara daxwazên bi derengiya ji 10ms mezintir jî zêde dike. Bi gotinek din, heke di 40k QPS de li ser 50ms li ser saniyeyê 50 daxwaz hebin, wê hingê di 1k QPS de her saniye 100 daxwaz li jor 50ms hebûn. Paradoks!

Tengkirina lêgerînê

Dema ku di pergalek belavkirî ya bi gelek pêkhateyan de bi pirsgirêkek derengmayînê re rû bi rû bimîne, gava yekem ew e ku meriv navnîşek kurt a gumanbaran biafirîne. Ka em hinekî kûrtir li mîmariya Alvin bikolin:

Xalek destpêkek baş navnîşek veguheztinên I/O yên ku hatine kirin e (bangên torê / lêgerîna dîskê, hwd.). Ka em hewl bidin ku derengî li ku derê ye. Ji xeynî I/O-ya eşkere ya bi xerîdar re, Alvin gavek zêde diavêje: ew digihîje dikana daneyê. Lêbelê, ev hilanîn di heman komê de wekî Alvin kar dike, ji ber vê yekê derengiya li wir divê ji xerîdar kêmtir be. Ji ber vê yekê, lîsteya gumanbaran:

1. Banga torê ji muwekîlê ji Alvin re.
2. Banga torê ji Alvin ji dikana daneyê.
3. Li ser dîskê li dikana daneyê bigerin.
4. Banga torê ji depoya daneyê ji Alvin re.
5. Banga torê ji Alvin ji muwekîlê re.

Ka em hewl bidin ku hin xalan derbas bikin.

Hilberîna daneyan bi wê re tiştek nîne

Yekem tiştê ku min kir ev bû ku Alvin veguherîne serverek ping-ping ku daxwazan pêvajo nake. Dema ku ew daxwazek distîne, ew bersivek vala vedigerîne. Ger dereng kêm bibe, wê hingê xeletiyek di pêkanîna Alvin an depoya daneyê de tiştek nedîtî ye. Di ceribandina yekem de em grafika jêrîn digirin:

Wekî ku hûn dikarin bibînin, dema ku hûn servera ping-ping bikar bînin çêtirbûnek tune. Ev tê vê wateyê ku depoya daneyê derengiyê zêde nake, û navnîşa gumanbaran di nîvî de tê qut kirin:

1. Banga torê ji muwekîlê ji Alvin re.
2. Banga torê ji Alvin ji muwekîlê re.

Ecêb! Lîsteya bi lez kêm dibe. Min fikir kir ku min hema sedem fêm kir.

gRPC

Naha dema wê ye ku hûn lîstikvanek nû bidin nasîn: gRPC. Ev pirtûkxaneyek çavkaniyek vekirî ya Google-ê ji bo pêwendiya di pêvajoyê de ye RPC... Herçi gRPC baş optîmîzekirin û bi berfirehî tê bikar anîn, ev cara yekem bû ku min wê li ser pergalek bi vî rengî bikar tînim û min hêvî dikir ku pêkanîna min ne-optimal be - bi kêmanî.

berdestbûnî gRPC di stûyê de pirsek nû derxist holê: dibe ku ew pêkanîna min an ez bixwe ye gRPC dibe sedema pirsgirêka derengiyê? Zêdekirina gumanbarek nû li navnîşê:

1. Xerîdar gazî pirtûkxaneyê dike gRPC
2. Pirtûkxaneyê gRPC li ser muwekîlê pirtûkxaneyê bangek torê dike gRPC li ser server
3. Pirtûkxaneyê gRPC têkilî Alvin (di doza servera ping-pong de operasyon tune)

Ji bo ku hûn ji we re ramanek bidin ku kod çawa xuya dike, pêkanîna muwekîlê min / Alvin ji yên muwekîlê-server ne pir cûda ye mînakên async.

Nîşe: Lîsteya jorîn hinekî hêsan e ji ber ku gRPC gengaz dike ku hûn modela xweya (şablon?) xêzkirinê bikar bînin, ku tê de stûna darvekirinê bi hev ve girêdayî ye. gRPC û pêkanîna bikarhêner. Ji bo sadebûnê, em ê li ser vê modelê bisekinin.

Profîlkirin dê her tiştî rast bike

Dema ku ez ji firotgehên daneyê derbas bûm, min fikirîn ku ez hema qediyam: "Naha ew hêsan e! Ka em profîlê bicîh bînin û fêr bibin ka dereng li ku derê çêdibe. ez heyranê mezin ê profîlkirina rast, ji ber ku CPU pir bi lez in û pir caran ne qalik in. Pir dereng diqewimin dema ku pêvajoyek pêdivî ye ku pêvajoyê rawestîne da ku tiştek din bike. Profîlkirina CPU-ya rast tenê wiya dike: ew her tiştî rast tomar dike veguherînên çarçoveyê û eşkere dike ku derengî çêdibin.

Min çar profîl girtin: bi QPS-ya bilind (derengiya kêm) û bi serverek ping-pongê bi QPS-ya nizm (derengiya bilind), hem li ser milê xerîdar û hem jî ji hêla serverê. Û tenê di rewşê de, min profîlek pêvajoyek nimûne jî girt. Dema ku profîlan berhev dikim, ez bi gelemperî li stûnek bangek anormal digerim. Mînakî, di aliyê xirab de bi derengiya bilind de gelek guhêrbarên kontekstê hene (10 car an jî zêdetir). Lê di doza min de, hejmara guheztinên kontekstê hema hema yek bû. Bi tirsa min, li wir tiştek girîng tune bû.

Debugging Additional

Ez di bêhêvîtiyê de bûm. Min nizanibû ku ez dikarim kîjan amûrên din bikar bînim, û plana min a paşîn bi bingehîn ev bû ku ez ceribandinan bi cûrbecûr cûda dubare bikim û ne ku pirsgirêkê bi zelalî teşhîs bikim.

Çi eger

Ez ji destpêkê ve di derbarê derengiya taybetî ya 50ms de fikar bûm. Ev demek pir mezin e. Min biryar da ku ez ê perçeyan ji kodê bibirim heya ku ez fêhm bikim ka kîjan beş dibe sedema vê xeletiyê. Dûv re ceribandinek hat ku xebitî.

Wekî gelemperî, di paşerojê de xuya dike ku her tişt eşkere bû. Min xerîdar li ser heman makîneyê wekî Alvin danî - û daxwazek jê re şand localhost. Û zêdebûna derengiyê çû!

Tiştek bi torê re xelet bû.

Fêrbûna jêhatîbûnên endezyarên torê

Divê ez bipejirînim: zanîna min a teknolojiyên torê tirsnak e, nemaze ji ber vê yekê ku ez her roj bi wan re dixebitim. Lê tora gumanbarê sereke bû, û ez hewce bûm ku ez fêr bibim ka meriv çawa wê jêbirin.

Xwezî, Înternet ji kesên ku dixwazin fêr bibin hez dike. Kombûna ping û tracert wekî destpêkek têra xwe baş xuya bû ji bo rakirina pirsgirêkên veguheztina torê.

Pêşî, min dest pê kir PsPing ji bo porta TCP ya Alvin. Min mîhengên xwerû bikar anîn - ne tiştek taybetî. Ji zêdetirî hezar ping, yek ji 10ms derbas nebû, ji bilî ya yekem ku germ bû. Ev berevajî zêdebûna dîtbarî ya derengiya 50 ms di sedî 99-an de ye: li wir, ji bo her 100 daxwazî, divê me hema yek daxwazek bi derengiya 50 ms dîtiba.

Paşê min hewl da tracer: Dibe ku pirsgirêkek li yek ji girêkên li ser riya di navbera Alvin û xerîdar de hebe. Lê şopger jî dest vala vegeriya.

Ji ber vê yekê ne koda min, pêkanîna gRPC, an torê bû ku bû sedema derengiyê. Min dest bi fikaran kir ku ez ê tu carî vê yekê fêm nekim.

Naha em li ser kîjan OS-ê ne

gRPC bi berfirehî li Linux-ê tê bikar anîn, lê li ser Windows-ê biyanî. Min biryar da ku ez ceribandinek biceribînim, ku xebitî: Min makîneyek virtual Linux afirand, Alvin ji bo Linux berhev kir, û ew bi cih kir.

Û li vir çi qewimî: servera ping-pongê ya Linux-ê wekî mêvandarek Windows-ê ya mîna heman dereng nebû, her çend çavkaniya daneyê ne cûda bû. Derket holê ku pirsgirêk di pêkanîna gRPC ya ji bo Windows-ê de ye.

algorîtmaya Nagle

Di vê demê de min digot qey ez alayek wenda dikim gRPC. Niha ez fêm dikim ku ew bi rastî çi ye gRPC Ala Windows winda ye. Min pirtûkxaneyek RPC ya navxweyî dît ku ez pê bawer bûm ku dê ji bo hemî alayên ku hatine danîn baş bixebite winsock. Dûv re min van hemî alayan li gRPC zêde kir û Alvin li ser Windows-ê, di serverek ping-pongê ya patchedkirî ya Windows-ê de bicîh kir!

Hema Qebû: Min dest bi rakirina alayên lêzêdekirî yek bi yek kir heya ku paşveçûn vegere da ku ez bikaribim sedemê diyar bikim. Bêrûmet bû TCP_NODELAY, Guhestina algorîtmaya Nagle.

algorîtmaya Nagle hewil dide ku hejmara pakêtên ku li ser torê têne şandin kêm bike bi derengkirina şandina peyaman heya ku mezinahiya pakêtê ji hejmareke diyarkirî ya byte derbas bibe. Her çend dibe ku ev ji bo bikarhênerê navîn xweş be, ew ji bo serverên rast-demê wêranker e ji ber ku OS dê hin peyaman dereng bike, û bibe sedema derengketina li ser QPS-ya kêm. U gRPC ev ala di pêkanîna Linux-ê de ji bo soketên TCP-ê hate danîn, lê ne di Windows-ê de. Ez ev im serrast kirin.

encamê

Derengiya bilind a li QPS-ya nizm ji hêla xweşbîniya OS-ê ve hatî çêkirin. Di paşerojê de, profîlek derengmayînê nas nekir ji ber ku ew di moda kernel de hate kirin û ne di nav de moda bikarhêner. Ez nizanim gelo algorîtmaya Nagle dikare bi girtina ETW were dîtin, lê ew ê balkêş be.

Di derbarê ceribandina localhost-ê de, dibe ku ew dest neda koda torê ya rastîn û algorîtmaya Nagle nexebitî, ji ber vê yekê pirsgirêkên derengiyê ji holê rabûn dema ku xerîdar bi riya localhost-ê gihîşt Alvin.

Cara din ku hûn zêdebûnek derengiyê bibînin ji ber ku jimara daxwaznameyên her çirkeyê kêm dibe, divê algorîtmaya Nagle di navnîşa weya gumanbaran de be!

Source: www.habr.com