Redis VPN bidez mantsoa sentitzen da: joan-etorri gutxiago eskaera bakoitzeko

Redis lokal baten aurka 200 ms-tan erantzuten duen orrialde batek lau segundo behar ditu bezeroa VPN baten atzean jartzen denean, zerbitzariko kontagailuak alferrik dauden bitartean. Erregistro geldoak ez du milisegundo batetik gorako ezer erakusten, CPUaren grafikoa laua da eta instantziak beste bezero batzuk zerbitzatzen ditu kexarik gabe. Aldatu dena distantzia da, eta distantzia biderkatzen duena zure kodea gelditu eta itxaroten duen aldi kopurua da. Egin eskaeraren bidea bezerotik kanporantz eta konponbidea ia beti da itxaronaldi sekuentzial gutxiago, zerbitzari azkarrago bat baino.

Hasi bezeroarengandik, ez zerbitzariaren metrikoetatik

Behatu bezeroaren prozesua lehenengo agindutik azkenera arte. Arrastoak erantzun bat, pausa bat eta gero hurrengo agindua erakusten baditu, agindu bakoitzeko joan-etorri osoa ordaintzen ari zara eta zerbitzariaren doikuntza edozeinek ere ez du hori aldatuko. Erregistro geldoa tresna okerra da hemen, exekuzio-denbora erregistratzen baitu eta komunikazio-I/Oa nahita kanpo uzten baitu. Erregistro geldo garbia endpoint geldo baten ondoan joan-etorri arazo baten sinadura da.

Neurtu bidea bera kodea ukitu aurretik. redis-cli -h redis.example.internal --latency etengabeko PINGak bidaltzen ditu eta eskaera eta erantzun denbora medioa inprimatzen du, hau da, zure truke-kostua. Biderkatu hori erabiltzaile ekintza bateko agindu sekuentzialen kopuruarekin eta endpointarentzat gutxieneko bat duzu.

Zenbatu erabiltzaile ekintza batek benetan behar dituen joan-etorriak

Hartu endpoint bakar bat eta idatzi Redis dei bakoitza ordenan, ORM, saio-middleware edo feature-flag bilaketa baten barruan ezkutatuta daudenak barne. Endpoint geldo gehienek hogei edo hogeita hamar dei egiten dituzte hiruk asko egingo luketen lekuan, eta ezkutukoak dira normalean gehiengoa.

Menpekotasun-kate bat ezin da tolestu: bigarren aginduak lehenengoak itzultzen duen gakoa behar badu, itxaronaldia erreala da eta aukera bakarrak datu-eredu desberdin bat edo pauso osoa batera adierazten duen zerbitzari aldeko eragiketa bat dira. Irakurketa independenteak beste kasu bat dira, ezerk ez dizulako behartzen bigarrena bidali aurretik lehen erantzunaren zain egotera. Markatu dei bakoitza mendeko edo independente gisa edozer aldatu aurretik, eta konponbidearen forma begi-bistakoa bihurtuko da.

Garrantzitsua den zenbakia itxaronaldi sekuentzialak dira, ez agindu guztiak. Batch bateko hogeita hamar aginduk itxaronaldi bakarra balio dute oraindik.

Batch-ean jarri elkarren mendeko ez diren aginduak soilik

Pipeline batek agindu independenteak ilaran jartzen ditu eta erantzunak ordenan biltzen ditu, N itxaronaldi bat bihurtuz. Bezero gehienek bloke, callback edo testuinguru-kudeatzaile gisa eskaintzen dute, konexio-modu bereizi gisa beharrean, beraz egiaztatu instalatutako bertsioak ematen duen APIa. Irabazia joan-etorri denborarekin eskalatzen da, eta horregatik da garrantzitsua VPN batean eta ia nabaritzen ez da localhost-en.

import redis

r = redis.Redis(host="redis.example.internal", port=6379, socket_timeout=2)
pipe = r.pipeline(transaction=False)
for key in ("user:1001", "user:1002", "user:1003"):
    pipe.get(key)
print(pipe.execute())

Pasa transaction=False batch-a soilik nahi duzunean. Lehenespenez bezeroak batch-a MULTI eta EXEC-en biltzen du, atomikoa eginez eta beste bezeroek hegaldian zer ikus dezaketen aldatuz. Atomikotasuna zuzenketaren erabakia da, ez errendimenduaren botoia, eta pipeline bat ez da transakzio biak joan-etorriak murrizten dituztelako soilik.

Irakurri erantzun bakoitza, batch-aren bidalketa soilik ez ezik. Ilararatutako agindu batek errore bat itzul dezake batch-a osorik amaitzen den bitartean, eta erantzunen zerrenda botatzen duen bezero batek huts egindako idazketa isil bat bihurtzen du. Konparatu erantzunen zerrendaren luzera ilararatutako agindu kopuruarekin.

Eduki konexioa bizirik ekintzen artean

Konexio berri bakoitzak izen-ebazpena, TCP eskuko larruazala, TLS eskuko larruazala eta AUTH ordaintzen ditu, eta VPN baten bidez horietako bakoitza ezin duzun joan-etorri bat da. Sortu bezeroa prozesu bakoitzeko behin eta erabili berriro, edo erabili zure liburutegiak eskaintzen duen pool mugatua. Eskaera bakoitzeko berriro konektatzea sintoma honen bigarren kausa ohikoena da agindu bakoitzeko itxaronaldeen ondoren.

Eduki host-izen pribatua konfigurazioan, helbide literal bat beharrean. Ziurtagiriaren baliozkotzea eta zerbitzuaren identitatea oraindik aplikatzen dira sare pribatu batean, eta IP bat finkatzeak apurtzen da hornitzaileak azpisare bat berriz zenbakitzen duen unean. Ebazpena zati geldoa bada, konpondu ebazlearen bidea, konexio-katea beharrean.

Ezarri socket-denborazko muga esplizitu bat, trabatutako tunel bat langile bat zintzilik uztearen ordez azkar huts egiteko. Gero egiaztatu pool-a benetan berrerabiltzen dela bezeroan konexio-sorkuntza erregistratuz.

Neurtu batch-a memoria-arazo bihurtu aurretik

Redisek ilararatutako erantzunak batch-aren iraunaldian zehar gordetzen ditu, eta bezeroak gero emaitza analizatua gordetzen du. Hamar mila balio handiko pipeline batek sareko itxaronaldiak memoria-piko eta bi muturretako pausa luzeengatik trukatzen ditu.

Aukeratu batch-tamaina erantzun-bolumenaren arabera, ez agindu kopuruaren arabera. Ehunka agindu txiki batch batean normalean erosoa da, baina ehun kilobyte anitzeko karga ez. Zatitu byteen arabera eta kopuruaren arabera ere, eta eduki batch bakoitza endpointak benetan duen latentzia-aurrekontuaren barruan.

Neurtu muturretik muturrera aldaketaren ondoren: redis-cli -h redis.example.internal --latency-history bideak berak egonkor jarraitzen duen erakusten du, eta zure eskaera-tenporizadoreak endpointak hobetu duen erakusten du. Endpointa oraindik motela bada latentzia-historia laua den bitartean, gainerako kostua zerbitzari aldeko lana edo zure serializazioa da, eta hurrengo pausoa kudeatzailearen profila da, ez beste batch-aldaketa bat.