Redis caur VPN šķiet lēns: mazāk gājienu turp un atpakaļ uz pieprasījumu

Lapa, kas atbild 200 ms laikā pret vietēju Redis, aizņem četras sekundes, tiklīdz klients atrodas aiz VPN, kamēr servera skaitītāji paliek dīkā. Lēnā žurnāla ierakstā nav nekas virs milisekundes, CPU grafiks ir plakans, un instance bez sūdzībām apkalpo citus klientus. Ir mainījies attālums, un attālumu reizina tas, cik reižu jūsu kods apstājas un gaida. Izstaigājiet pieprasījuma ceļu no klienta uz āru, un risinājums gandrīz vienmēr ir mazāk secīgu gaidīšanu, nevis ātrāks serveris.

Sāciet no klienta, nevis no servera metrikas

Vērojiet klienta procesu starp pirmo un pēdējo komandu. Ja pēdas rāda atbildi, pauzi un tad nākamo komandu, jūs maksājat pilnu gājienu turp un atpakaļ par katru komandu, un nekāda servera regulēšana to nemainīs. Lēnā žurnāla ieraksts šeit ir nepareizais rīks, jo tas reģistrē izpildes laiku un apzināti izslēdz komunikācijas I/O. Tīrs lēns žurnāls blakus lēnam galapunktam ir gājienu turp un atpakaļ problēmas paraksts.

Izmēriet pašu ceļu, pirms pieskaraties kodam. redis-cli -h redis.example.internal --latency sūta atkārtotus PING un izdrukā vidējo pieprasījuma un atbildes laiku, kas ir jūsu izmaksas par vienu apmaiņu. Reiziniet to ar secīgo komandu skaitu vienā lietotāja darbībā, un jums būs galapunkta apakšējā robeža.

Saskaitiet gājienus turp un atpakaļ, kas vienai lietotāja darbībai tiešām vajadzīgi

Paņemiet vienu galapunktu un pēc kārtas pierakstiet katru Redis izsaukumu, tostarp tos, kas paslēpti ORM, sesijas starpprogrammatūrā vai funkciju karodziņa meklēšanā. Lielākā daļa lēno galapunktu izdara divdesmit vai trīsdesmit izsaukumus tur, kur pietiktu ar trim, un paslēptie parasti ir vairākums.

Atkarību ķēdi nevar salocīt: ja otrajai komandai vajag atslēgu, ko atgriež pirmā, gaidīšana ir īsta, un vienīgās iespējas ir cits datu modelis vai servera puses operācija, kas izsaka visu soli uzreiz. Neatkarīgas lasīšanas ir cits gadījums, jo nekas neliek gaidīt pirmo atbildi pirms otrās sūtīšanas. Atzīmējiet katru izsaukumu kā atkarīgu vai neatkarīgu, pirms kaut ko maināt, un risinājuma forma kļūs acīmredzama.

Svarīgais skaitlis ir secīgas gaidīšanas, nevis kopējās komandas. Trīsdesmit komandas vienā partijā joprojām maksā vienu gaidīšanu.

Partijā iekļaujiet tikai tās komandas, kas nav atkarīgas viena no otras

Cauruļvads ievieto neatkarīgas komandas rindā un savāc atbildes secībā, pārvēršot N gaidīšanas vienā. Lielākā daļa klientu to piedāvā kā bloku, atzvanīšanu vai konteksta pārvaldnieku, nevis atsevišķu savienojuma režīmu, tāpēc pārbaudiet API, ko nodrošina jūsu instalētā versija. Ieguvums aug līdz ar gājiena laiku, un tieši tāpēc tas ir svarīgs VPN un gandrīz nav jūtams localhost.

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())

Nododiet transaction=False, ja vēlaties tikai partijas veidošanu. Pēc noklusējuma klients iesaiņo partiju MULTI un EXEC, kas padara to atomāru un maina to, ko citi klienti var novērot lidojuma laikā. Atomaritāte ir pareizības lēmums, nevis veiktspējas kloķis, un cauruļvads nav transakcija tikai tāpēc, ka abi samazina gājienus.

Lasiet katru atbildi, nevis tikai partijas iesniegšanu. Rindā ievietota komanda var atgriezt kļūdu, kamēr partija kopumā tiek pabeigta, un klients, kas izmet atbilžu sarakstu, neizdevušos rakstīšanu pārvērš klusā. Salīdziniet atbilžu saraksta garumu ar rindā ievietoto komandu skaitu.

Turiet savienojumu dzīvu starp darbībām

Katrs jauns savienojums maksā par vārdu izšķiršanu, TCP rokasspiedienu, TLS rokasspiedienu un AUTH, un VPN gadījumā katrs no tiem ir gājiens, ko nevarat iekļaut partijā. Izveidojiet klientu vienreiz uz procesu un izmantojiet to atkārtoti, vai izmantojiet jūsu bibliotēkas piedāvāto baseinu ar ierobežotu lielumu. Atkārtota savienošanās katram pieprasījumam ir otrs visbiežākais šī simptoma cēlonis aiz gaidīšanām uz komandu.

Turiet privāto resursdatora nosaukumu konfigurācijā, nevis burtisku adresi. Sertifikāta validācija un pakalpojuma identitāte joprojām attiecas uz privātu tīklu, un IP piespraušana salūzt tajā brīdī, kad pakalpojumu sniedzējs pārnumurē apakštīklu. Ja izšķiršana ir lēnā daļa, labojiet atrisinātāja ceļu, nevis savienojuma virkni.

Iestatiet skaidru ligzdas taimautu, lai iesprūdis tunelis ātri ciestu neveiksmi, nevis pakārtu darbinieku. Pēc tam apstipriniet, ka baseins tiešām tiek izmantots atkārtoti, reģistrējot savienojumu izveidi klientā.

Nosakiet partijas lielumu, pirms tā kļūst par atmiņas problēmu

Redis glabā rindā esošās atbildes visu partijas laiku, un klients pēc tam glabā parsēto rezultātu. Cauruļvads ar desmit tūkstošiem lielu vērtību apmaina tīkla gaidīšanas pret atmiņas lēcieniem un garām pauzēm abos galos.

Izvēlieties partijas lielumu pēc atbildes apjoma, nevis komandu skaita. Daži simti mazu komandu vienā partijā parasti ir ērti, savukārt simts vairāku kilobaitu kravu nav. Sadaliet pēc baitiem un arī pēc skaita, un turiet katru partiju latentuma budžetā, kas galapunktam tiešām ir.

Pēc izmaiņām nomēriet no gala līdz galam: redis-cli -h redis.example.internal --latency-history parāda, vai pats ceļš ir stabils, un jūsu paša pieprasījumu taimeris parāda, vai galapunkts uzlabojās. Ja galapunkts joprojām ir lēns, kamēr latentuma vēsture ir plakana, atlikušās izmaksas ir servera puses darbs vai jūsu paša serializācija, un nākamais solis ir apstrādātāja profils, nevis vēl viena partijas izmaiņa.