Wéi an meescht posts, et gëtt e Problem mat engem verdeelt Service, loosst eis dëse Service Alvin nennen. Dës Kéier hunn ech de Problem selwer net entdeckt, hunn d'Kärelen vun der Clientssäit mech informéiert.

Enges Daags sinn ech mat enger onzefriddener E-Mail erwächt wéinst laange Verspéidungen mam Alvin, déi mir geplangt hunn an der nächster Zukunft ze lancéieren. Speziell huet de Client 99th percentile latency an der Regioun vun 50 ms erlieft, wäit iwwer eisem latency Budget. Dëst war iwwerraschend wéi ech de Service extensiv getest hunn, besonnesch op Latenz, wat eng gemeinsam Plainte ass.

Ier ech den Alvin an d'Test gesat hunn, hunn ech vill Experimenter mat 40k Ufroen pro Sekonn (QPS) gemaach, déi all latency vu manner wéi 10ms weisen. Ech war bereet ze erklären datt ech net mat hire Resultater averstane sinn. Awer nach eng Kéier op de Bréif gekuckt, hunn ech eppes Neies gemierkt: Ech hat d'Konditiounen net genau getest, déi se ernimmt hunn, hir QPS war vill méi niddereg wéi mäin. Ech getest op 40k QPS, mä si nëmmen op 1k. Ech hunn en anert Experiment gemaach, dës Kéier mat engem nidderegen QPS, just fir se ze berouegen.

Well ech iwwer dëst bloggen, hutt Dir wahrscheinlech schonn erausfonnt datt hir Zuelen richteg waren. Ech hunn mäi virtuelle Client ëmmer erëm getest, mam selwechte Resultat: eng kleng Unzuel vun Ufroen erhéicht net nëmmen d'Latenz, mee erhéicht d'Zuel vun Ufroen mat enger latency vu méi wéi 10 ms. An anere Wierder, wann bei 40k QPS ongeféier 50 Ufroe pro Sekonn 50 ms iwwerschratt hunn, da bei 1k QPS goufen et 100 Ufroen iwwer 50 ms all Sekonn. Paradox!

D'Sich schmuel

Wann Dir mat engem Latenzproblem an engem verdeelte System mat ville Komponenten konfrontéiert sidd, ass den éischte Schrëtt eng kuerz Lëscht vu Verdächtegen ze kreéieren. Loosst eis e bësse méi déif an dem Alvin seng Architektur gräifen:

E gudde Startpunkt ass eng Lëscht vun ofgeschlossen I/O Iwwergäng (Netzwierker/Disk Lookups, etc.). Loosst eis probéieren erauszefannen, wou d'Verspéidung ass. Nieft dem offensichtlechen I/O mam Client, mécht den Alvin en extra Schrëtt: hien huet Zougang zum Dategeschäft. Wéi och ëmmer, dës Späichere funktionnéiert am selwechte Cluster wéi Alvin, sou datt d'Latenz do manner sollt sinn wéi mam Client. Also, d'Lëscht vun de Verdächtegen:

1. Reseau Uruff vum Client un Alvin.
2. Reseau Uruff vum Alvin an den Dategeschäft.
3. Sich op Disk am Dategeschäft.
4. Reseau Uruff vum Datelager op Alvin.
5. Reseau Uruff vun Alvin zu engem Client.

Loosst eis probéieren e puer Punkten erauszekréien.

Datespeicherung huet näischt domat ze dinn

Déi éischt Saach, déi ech gemaach hunn, war den Alvin op e Ping-Ping-Server konvertéieren deen d'Ufroe net veraarbecht. Wann et eng Ufro kritt, gëtt et eng eidel Äntwert zréck. Wann d'Latenz erofgeet, dann ass e Feeler an der Alvin- oder Datelagerimplementatioun näischt ongehéiert. Am éischten Experiment kréie mir déi folgend Grafik:

Wéi Dir kënnt gesinn, gëtt et keng Verbesserung wann Dir de Ping-Ping Server benotzt. Dëst bedeit datt d'Datelager d'Latenz net erhéicht, an d'Lëscht vun de Verdächtegen an der Halschent geschnidden:

1. Reseau Uruff vum Client un Alvin.
2. Reseau Uruff vun Alvin zu engem Client.

Super! D'Lëscht schrumpft séier. Ech hu geduecht datt ech de Grond bal erausfonnt hunn.

gRPC

Elo ass d'Zäit Iech en neie Spiller virzestellen: gRPC. Dëst ass eng Open Source Bibliothéik vu Google fir am Prozess Kommunikatioun RPC-... Och wann gRPC gutt optimiséiert a wäit benotzt, dëst war meng éischte Kéier et op engem System vun dëser Gréisst benotzt an ech erwaart meng Ëmsetzung suboptimal gin - op d'mannst ze soen.

Disponibilitéit gRPC am Stack huet eng nei Fro gestallt: vläicht ass et meng Ëmsetzung oder ech selwer gRPC Ursaach latency Problem? En neie Verdächtegen op d'Lëscht bäidroen:

1. De Client rifft d'Bibliothéik gRPC
2. Bibliothéik gRPC mécht en Netz Opruff un d'Bibliothéik op de Client gRPC op Server
3. Bibliothéik gRPC Kontakter Alvin (keng Operatioun am Fall vu Ping-Pong Server)

Fir Iech eng Iddi ze ginn wéi de Code ausgesäit, ass mäi Client / Alvin Implementatioun net vill anescht wéi de Client-Server async Beispiller.

Notiz: Déi uewe genannte Lëscht ass e bësse vereinfacht well gRPC mécht et méiglech Ären eegene (Schabloun?) Threading-Modell ze benotzen, an deem den Ausféierungsstack matenee verbonnen ass gRPC an Benotzer Ëmsetzung. Fir d'Einfachheet wäerte mir un dësem Modell halen.

Profiling wäert alles fixéieren

Nodeems ech d'Dategeschäfter duerchgestrachen hunn, hunn ech geduecht datt ech bal fäerdeg wier: "Elo ass et einfach! Loosst eis de Profil uwenden an erausfannen wou d'Verspéidung geschitt. ech grousse Fan vun Präzisioun profiling, well CPUs ganz séier sinn an am meeschten net de Flaschenhals sinn. Déi meescht Verspéidungen trëtt op wann de Prozessor d'Veraarbechtung muss ophalen fir eppes anescht ze maachen. Genau CPU Profiling mécht just dat: et registréiert alles genau Kontext schalt a mécht kloer wou Verspéidungen optrieden.

Ech hunn véier Profiler geholl: mat héijer QPS (niddereg latency) a mat engem Ping-Pong-Server mat gerénger QPS (héich latency), souwuel op der Clientssäit wéi och op der Serversäit. A just am Fall, Ech hunn och e Prouf Prozessor Profil geholl. Wann Dir Profiler vergläicht, sichen ech normalerweis no engem anomalen Uruffstack. Zum Beispill, op der schlechter Säit mat héijer latency ginn et vill méi Kontextschalter (10 Mol oder méi). Awer a mengem Fall war d'Zuel vun de Kontextschalter bal d'selwecht. Zu menger Schrecken war do näischt Wichtegst.

Zousätzlech Debugging

Ech war verzweifelt. Ech wousst net wéi eng aner Tools ech benotze konnt, a mäi nächste Plang war am Fong d'Experimenter mat verschiddene Variatiounen ze widderhuelen anstatt de Problem kloer ze diagnostizéieren.

Wat wier wann

Vun Ufank u war ech besuergt iwwer déi spezifesch 50ms Latenz. Dëst ass eng ganz grouss Zäit. Ech hu beschloss datt ech Stécker aus dem Code schneiden bis ech genau erausfannen wéi en Deel dëse Feeler verursaacht huet. Dunn koum en Experiment dat geklappt huet.

Wéi gewinnt, am Réckbléck schéngt et datt alles evident war. Ech hunn de Client op déi selwecht Maschinn wéi Alvin gesat - an eng Demande geschéckt localhost. An d'Erhéijung vun der latency ass fort!

Eppes war falsch mam Netz.

Léieren Reseau Ingenieur Kompetenzen

Ech muss zouginn: mäi Wëssen iwwer Netzwierktechnologien ass schrecklech, besonnesch wann Dir bedenkt datt ech all Dag mat hinnen schaffen. Awer d'Netzwierk war den Haaptverdächtegen, an ech muss léieren wéi ech et debuggen.

Glécklech, den Internet gär déi, déi léieren wëllen. D'Kombinatioun vu Ping an Tracert schénge wéi e gutt genuch Start fir Netzwierktransportproblemer ze Debuggéieren.

Als éischt hunn ech lancéiert PsPeng zu Alvin d'TCP port. Ech hunn d'Standardastellungen benotzt - näischt Besonnesches. Vun méi wéi dausend Pings ass keen iwwerschratt 10 ms, mat Ausnam vun der éischter fir Erwiermung. Dëst ass am Géigesaz zu der observéierter Erhéijung vun der Latenz vun 50 ms um 99. Prozenttil: do, fir all 100 Ufroe, sollte mir ongeféier eng Ufro mat enger latency vu 50 ms gesinn.

Dunn hunn ech probéiert Tracert: Et kann e Problem op ee vun de Wirbelen laanscht de Wee tëscht Alvin an de Client ginn. Awer de Spuerer ass och mat eidelen Hänn zréckkomm.

Also et war net mäi Code, d'gRPC Implementatioun oder d'Netzwierk déi d'Verzögerung verursaacht hunn. Ech war ugefaang ze Suergen, datt ech dat ni géif verstoen.

Elo wat OS si mir op

gRPC vill op Linux benotzt, awer exotesch op Windows. Ech hu beschloss en Experiment ze probéieren, wat geschafft huet: Ech hunn eng virtuell Linux Maschinn erstallt, Alvin fir Linux kompiléiert an ofgesat.

An hei ass wat geschitt ass: de Linux Ping-Pong Server huet net déiselwecht Verzögerungen wéi en ähnlechen Windows Host, obwuel d'Datequell net anescht war. Et stellt sech eraus datt de Problem an der gRPC Implementatioun fir Windows ass.

Nagle's Algorithmus

All dës Kéier hunn ech geduecht datt ech e Fändel fehlen gRPC. Elo verstinn ech wat et wierklech ass gRPC Windows Fändel fehlt. Ech hunn eng intern RPC Bibliothéik fonnt, datt ech zouversiichtlech war gutt fir all Fändelen Formatioun Aarbecht Winsock. Dunn hunn ech all dës Fändelen op gRPC bäigefüügt an den Alvin op Windows ofgesat, an engem patched Windows Ping-Pong Server!

Bal Gemaach: Ech hunn ugefaang déi addéiert Fändelen een an enger Zäit ze läschen bis d'Regressioun zréckkoum sou datt ech d'Ursaach konnt feststellen. Et war berühmt TCP_NODELAY, Nagle Algorithmus Schalter.

Nagle's Algorithmus probéiert d'Zuel vun de Pakete, déi iwwer e Netzwierk geschéckt ginn, ze reduzéieren andeems d'Transmissioun vu Messagen ze verzögern ass, bis d'Paketgréisst eng gewëssen Unzuel u Bytes iwwerschreift. Och wann dëst fir den duerchschnëttleche Benotzer schéin ass, ass et zerstéierend fir Echtzäitserver well d'OS e puer Messagen verzögert, wat Lags op niddereg QPS verursaacht. U gRPC dëse Fändel gouf an der Linux Implementatioun fir TCP Sockets gesat, awer net a Windows. Ech sinn dëst korrigéiert.

Konklusioun

Déi méi héich Latenz bei niddereg QPS gouf duerch OS Optimisatioun verursaacht. Am Réckbléck huet d'Profiling keng latency erkannt well et am Kernelmodus gemaach gouf anstatt am Benotzer Modus. Ech weess net ob dem Nagle säin Algorithmus duerch ETW Capture observéiert ka ginn, awer et wier interessant.

Wat de localhost Experiment ugeet, huet et wahrscheinlech net den aktuellen Netzwierkcode beréiert an dem Nagle säin Algorithmus huet net gelaf, sou datt d'Latenzprobleemer fortgaang sinn wann de Client den Alvin duerch localhost erreecht huet.

Déi nächst Kéier wann Dir eng Erhéijung vun der Latenz gesitt wéi d'Zuel vun den Ufroen pro Sekonn erofgeet, sollt dem Nagle säin Algorithmus op Ärer Lëscht vu Verdächtegen sinn!

Source: will.com