Redis VPN-i taga tundub aeglane: vähem edasi-tagasi käike päringu kohta

Leht, mis vastab kohaliku Redis vastu 200 ms-ga, võtab neli sekundit, kui klient istub VPN-i taga, samal ajal kui serveri loendurid seisavad jõude. Aeglane logi ei näita midagi üle millisekundi, CPU graafik on tasane ja instants teenindab teisi kliente kaebusteta. Muutus on vahemaa ja vahemaad korrutab see, kui mitu korda teie kood peatub ja ootab. Käige päringu tee kliendist väljapoole läbi ja lahendus on peaaegu alati vähem järjestikuseid ootamisi, mitte kiirem server.

Alustage kliendist, mitte serveri mõõdikutest

Jälgige kliendi protsessi esimese ja viimase käsu vahel. Kui jälg näitab vastust, pausi ja seejärel järgmist käsku, maksate iga käsu eest täieliku edasi-tagasi käigu ja ükski serveri häälestus ei muuda seda. Aeglane logi on siin vale tööriist, sest see salvestab täitmisaega ja jätab side-I/O meelega välja. Puhas aeglane logi aeglase lõpp-punkti kõrval on edasi-tagasi käigu probleemi tunnus.

Mõõtke rada ennast enne, kui koodi puudutate. redis-cli -h redis.example.internal --latency saadab korduvaid PING-e ja trükib keskmise päringu- ja vastuseaja, mis on teie kulu ühe vahetuse kohta. Korrutage see ühe kasutajategevuse järjestikuste käskude arvuga ja saate lõpp-punkti jaoks alumise piiri.

Loendage edasi-tagasi käigud, mida üks kasutajategevus tegelikult vajab

Võtke üks lõpp-punkt ja kirjutage üles iga Redis-kutse järjekorras, kaasa arvatud need, mis on peidetud ORM-i, sessiooni vahevara või funktsioonilipu otsingusse. Enamik aeglaseid lõpp-punkte teeb lõpuks kakskümmend või kolmkümmend kutset seal, kus kolmest piisaks, ja peidetud on tavaliselt enamik.

Sõltuvusahelat ei saa kokku voltida: kui teine käsk vajab võtit, mille esimene tagastab, on ootamine tõeline ja ainsad valikud on teine andmemudel või serveripoolne toiming, mis väljendab kogu sammu korraga. Sõltumatud lugemised on teine juhtum, sest miski ei sunni teid enne teise saatmist esimest vastust ootama. Märkige iga kutse enne muudatuste tegemist sõltuvaks või sõltumatuks ja lahenduse kuju muutub ilmselgeks.

Tähtis arv on järjestikused ootamised, mitte käskude koguarv. Kolmkümmend käsku ühes partiis maksavad ikkagi ühe ootamise.

Pange partiisse ainult käsud, mis ei sõltu üksteisest

Konveier paneb sõltumatud käsud järjekorda ja kogub vastused järjekorras, muutes N ootamist üheks. Enamik kliente pakub seda ploki, callback'i või kontekstihaldurina, mitte eraldi ühendusrežiimina, seega kontrollige API-t, mille teie paigaldatud versioon pakub. Kasu kasvab edasi-tagasi käigu ajaga ja just seetõttu loeb see VPN-i puhul ning on localhostis vaevu märgatav.

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

Edastage transaction=False, kui soovite ainult partii koostamist. Vaikimisi mähitab klient partii MULTI ja EXEC sisse, mis teeb selle atomaarseks ja muudab seda, mida teised kliendid lennu ajal näha võivad. Atomaarsus on korrektsuse otsus, mitte jõudluse nupp, ja konveier ei ole tehing ainult seetõttu, et mõlemad vähendavad edasi-tagasi käike.

Lugege iga vastust, mitte ainult partii esitamist. Järjekorda pandud käsk võib tagastada vea, samal ajal kui partii tervikuna lõpeb, ja klient, kes vastuste nimekirja ära viskab, muudab ebaõnnestunud kirjutise vaikseks. Võrrelge vastuste nimekirja pikkust järjekorda pandud käskude arvuga.

Hoidke ühendus tegevuste vahel elus

Iga uus ühendus maksab nime lahendamise, TCP käepigistuse, TLS käepigistuse ja AUTH-i eest ning VPN-i korral on igaüks neist edasi-tagasi käik, mida ei saa partiisse panna. Looge klient üks kord protsessi kohta ja kasutage uuesti või kasutage teegi pakutavat piiratud suurusega basseini. Iga päringu puhul uuesti ühendamine on selle sümptomi teine kõige tavalisem põhjus pärast käsu kohta ootamist.

Hoidke privaatne hostinimi konfiguratsioonis, mitte sõnasõnaline aadress. Sertifikaadi valideerimine ja teenuse identiteet kehtivad endiselt privaatvõrgus ning IP kinnitamine katkeb hetkel, mil teenusepakkuja alamsuvõrgu ümber nummerdab. Kui lahendamine on aeglane osa, parandage lahendaja rada, mitte ühendusstring.

Seadke selgesõnaline socketi ajalõpp, et takerdunud tunnel ebaõnnestuks kiiresti, mitte ei jätaks töötajat rippuma. Seejärel kinnitage, et basseini tõesti uuesti kasutatakse, logides kliendis ühenduste loomist.

Mõõtke partii suurus enne, kui sellest saab mäluhäda

Redis hoiab järjekorda pandud vastuseid kogu partii vältel ja klient hoiab seejärel parsitud tulemust. Kümne tuhande suure väärtuse konveier vahetab võrguootamised mälutippude ja pikkade pauside vastu mõlemas otsas.

Valige partii suurus vastuste mahu, mitte käskude arvu järgi. Mõnisada väikest käsku ühes partiis on tavaliselt mugav, samas kui sada mitmekilobaidist kandekoormat ei ole. Jagage nii baitide kui ka arvu järgi ja hoidke iga partii lõpp-punkti tegeliku latentsuseelarve piires.

Mõõtke pärast muudatust otsast otsani: redis-cli -h redis.example.internal --latency-history näitab, kas rada ise on stabiilne, ja teie enda päringutaimer näitab, kas lõpp-punkt paranes. Kui lõpp-punkt on endiselt aeglane, samal ajal kui latentsuse ajalugu on tasane, on ülejäänud kulu serveripoolne töö või teie enda serialiseerimine, ja järgmine samm on käsitleja profiil, mitte veel üks partiimuudatus.