Redis oer in VPN fielt stadich: minder hinne-en-wer werom per oanfraach

In side dy't yn 200 ms antwurtet tsjin in lokaal Redis docht der fjouwer sekonden oer sadree't de klant efter in VPN sit, wylst de tsjinstellingstallers fan de tsjinner stil bliuwe. It stadige logboek lit neat boppe in millisekonde sjen, de CPU-grafyk is flak, en de ynstânsje betsjinnet oare klanten sûnder klacht. Wat feroare is, is de ôfstân, en wat de ôfstân fermannichfâldiget, is it oantal kearen dat jo koade stopet en wachtet. Rin it paad fan de oanfraach fan de klant nei bûten en de oplossing is hast altyd minder opienfolgjende wachtens earder as in rapper tsjinner.

Begjin by de klant, net by de tsjinner syn mjitmaten

Besjoch it klantproses tusken it earste kommando en it lêste. As it spoar in antwurd, in skoft en dan it folgjende kommando sjen lit, betelje jo in folsleine hinne-en-wer per kommando en gjin hoemannichte tsjinnerôfstimming sil dat feroarje. It stadige logboek is hjir it ferkearde ynstrumint, omdat it útfiertiid fêstleit en kommunikaasje-I/O mei opsetsin útslút. In skjin stadich logboek njonken in stadich einpunt is it signature fan in hinne-en-wer probleem.

Mjit it paad sels foardat jo koade oanreitsje. redis-cli -h redis.example.internal --latency stjoert werhelle PING's en prints it gemiddelde oanfraach- en antwurdtid, dat is jo kosten per útwikseling. Fermannichfâldigje dat mei it oantal opienfolgjende kommando's yn ien brûkeraksje en jo hawwe in ûndergrins foar it einpunt.

Tel de hinne-en-wer werom dy't ien brûkeraksje wier nedich hat

Nim ien einpunt en skriuw elk Redis-oprop op folchoarder, ynklusyf dy't ferstoppe binne yn in ORM, in sesje-middleware of in feature-flag-opmaak. De measte stadige einpunten docht bliken tweintich of tritich oproppen te meitsjen wylst trije genôch wiene, en de ferstoppe binne meastal de mearderheid.

In ôfhinklikensketen kin net ynklapt wurde: as it twadde kommando de kaai nedich hat dy't it earste weromjout, is de wachttiid echt en de iennichste opsjes binne in oar gegevensmodel of in tsjinnerkant-operaasje dy't de hiele stap yn ien kear útdrukt. Unôfhinklike lêzen binne in oar gefal, omdat neat jo twingt te wachtsjen op it earste antwurd foardat jo it twadde stjoere. Markearje elk oprop as ôfhinklik of unôfhinklik foardat jo wat bewurkje, en de foarm fan de oplossing wurdt dúdlik.

It getal dat fan belang is, binne opienfolgjende wachtens, net totale kommando's. Tritich kommando's yn ien partij kostet noch altyd ien wachttiid.

Partij allinnich de kommando's dy't net fan inoar ôfhinklik binne

In pipeline set unôfhinklike kommando's yn 'e wachtrige en sammelt de antwurden yn folchoarder, en makket fan N wachtens ien. De measte klanten biede it as in blok, in callback of in kontekstbehearder oan ynstee fan in aparte ferbiningsmodus, dus kontrolearje de API dy't jo ynstalleare ferzje leveret. De winst skaalet mei de hinne-en-wer tiid, en dêrom krekt is it fan belang op in VPN en hast net te fernimmen op 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())

Jou transaction=False troch as jo allinnich partijfoarming wolle. Mei de standert wikkelet de klant de partij yn MULTI en EXEC, wat it atomêr makket en feroaret wat oare klanten midden yn 'e flecht observearje kinne. Atomisiteit is in beslissing oer korrektheid, net in prestaasjeknop, en in pipeline is gjin transaksje allinnich om't beide hinne-en-wer werom ferminderje.

Lês elk antwurd ynstee fan allinnich it partijynstjoeren. In kommando yn 'e wachtrige kin in flater weromjaan wylst de partij as gehiel foltôget, en in klant dy't de antwurdlist fuortsmyt makket fan in mislearre skriuwing in stille. Ferlykje de lingte fan de antwurdlist mei it oantal kommando's dat jo yn 'e wachtrige set hawwe.

Hâld de ferbining libben tusken aksjes

Elke nije ferbining betellet foar nammeoplossing, in TCP-hânskodding, in TLS-hânskodding en in AUTH, en oer in VPN is elk dêrfan in hinne-en-wer dy't jo net partijje kinne. Meitsje de klant ien kear per proses en brûk him opnij, of brûk de pool dy't jo bibleteek biedt mei in beheinde grutte. Opnij ferbine per oanfraach is de twadde meast foarkommende oarsaak fan dit symptoom nei wachtens per kommando.

Hâld de privee hostnamme yn 'e konfiguraasje ynstee fan in letterlike adres. Sertifikaatfalidaasje en tsjinstidentiteit jilde noch op in privee netwurk, en it fêstspijkere fan in IP brekt op it momint dat de leveransier in subnet fernûmeret. As oplossing it stadige diel is, meitsje it resolverpaad klear ynstee fan de ferbiningstekst.

Set in eksplisite socket-timeout sadat in fêst sleatende tunnel fluch mislearret ynstee fan in wurker te hingen. Befêstigje dan dat de pool wier opnij brûkt wurdt troch ferbiningskreaasje yn 'e klant te loggen.

Bepaal de partijgrutte foardat it in ûnthâldprobleem wurdt

Redis hâldt wachtrige antwurden foar de doer fan in partij, en de klant hâldt dêrnei it parsearre resultaat. In pipeline fan tsien tûzen grutte wearden ruilet netwurkwachtens foar ûnthâldspitzen en lange skoften oan beide kanten.

Kies in partijgrutte tsjin antwurdvolumint ynstee fan kommandotel. In pear hûndert lytse kommando's yn ien partij is meastal noflik, wylst hûndert multi-klibyte ladingen dat net binne. Diel nei bytes likegoed as nei tal, en hâld elke partij binnen it latency-begrutting dat it einpunt wier hat.

Mjit fan ein oant ein nei de feroaring: redis-cli -h redis.example.internal --latency-history lit sjen oft it paad sels stabyl is, en jo eigen oanfraachtimer lit sjen oft it einpunt ferbettere. As it einpunt noch stadich is wylst de latency-skiednis flak is, is de oerbleaune kosten tsjinnerkantwurk of jo eigen serialisaasje, en de folgjende stap is in profyl fan 'e handler ynstee fan noch in partijferoaring.