A Redis VPN-en lassúnak tűnik: kevesebb oda-vissza út kérésenként

Egy oldal, amely helyi Redis ellen 200 ms alatt válaszol, négy másodpercet vesz igénybe, amint az ügyfél VPN mögé kerül, miközben a szerver számlálói tétlenek maradnak. A lassú napló semmit nem mutat egy ezredmásodperc felett, a CPU-grafikon lapos, és a példány panasz nélkül szolgál ki más ügyfeleket. Ami változott, az a távolság, és ami megsokszorozza a távolságot, az az a sokszor, ahányszor a kódja megáll és vár. Járja végig a kérés útját az ügyféltől kifelé, és a megoldás szinte mindig kevesebb egymás utáni várakozás, nem pedig gyorsabb szerver.

Az ügyfélnél kezdje, ne a szerver mérőszámainál

Figyelje az ügyfélfolyamatot az első és az utolsó parancs között. Ha a nyomkövetés választ, szünetet, majd a következő parancsot mutat, parancsonként egy teljes oda-vissza utat fizet, és a szerverhangolás semmilyen mértéke nem változtat ezen. A lassú napló itt rossz eszköz, mert végrehajtási időt rögzít, és a kommunikációs I/O-t szándékosan kizárja. Egy tiszta lassú napló egy lassú végpont mellett az oda-vissza út problémájának a jele.

Mérje meg magát az utat, mielőtt a kódhoz nyúlna. redis-cli -h redis.example.internal --latency ismételt PING-eket küld, és kiírja az átlagos kérés- és válaszidőt, ami az Ön csereként fizetett költsége. Szorozza meg ezt egy felhasználói művelet egymás utáni parancsainak számával, és megkapja a végpont alsó korlátját.

Számolja meg, hány oda-vissza útra van tényleg szüksége egy felhasználói műveletnek

Vegyen egyetlen végpontot, és írja fel sorrendben az összes Redis-hívást, beleértve azokat, amelyek egy ORM, egy munkamenet-köztes réteg vagy egy funkciókapcsoló-keresés belsejében rejtőznek. A legtöbb lassú végpont húsz vagy harminc hívást tesz ott, ahol három is elég volna, és a rejtettek általában többségben vannak.

Egy függőségi láncot nem lehet összecsukni: ha a második parancsnak arra a kulcsra van szüksége, amelyet az első ad vissza, a várakozás valódi, és az egyetlen lehetőség egy másik adatmodell vagy egy kiszolgálóoldali művelet, amely az egész lépést egyszerre fejezi ki. A független olvasások más eset, mert semmi nem kényszeríti arra, hogy megvárja az első választ a második elküldése előtt. Jelöljön meg minden hívást függőként vagy függetlenként, mielőtt bármit szerkesztene, és a megoldás formája nyilvánvalóvá válik.

A szám, amely számít, az egymás utáni várakozás, nem az összes parancs. Harminc parancs egy kötegben így is egy várakozásba kerül.

Csak azokat a parancsokat kötegelje, amelyek nem függenek egymástól

A csővezeték független parancsokat sorol be és sorrendben gyűjti a válaszokat, N várakozást eggyé alakítva. A legtöbb ügyfél blokként, visszahívásként vagy kontextuskezelőként kínálja, nem külön kapcsolati módként, ezért ellenőrizze a telepített verziója által kínált API-t. A nyereség az oda-vissza út idejével nő, és éppen ezért számít VPN-en, localhoston pedig alig észrevehető.

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

Adja át a transaction=False értéket, ha csak kötegelni akar. Alapértelmezés szerint az ügyfél MULTI és EXEC közé csomagolja a köteget, ami atomivá teszi, és megváltoztatja, mit figyelhetnek meg más ügyfelek repülés közben. Az atomitás helyességi döntés, nem teljesítménygomb, és a csővezeték nem tranzakció csak azért, mert mindkettő csökkenti az oda-vissza utakat.

Minden választ olvasson el, ne csak a köteg elküldését. Egy sorba állított parancs hibát adhat vissza, miközben a köteg egésze befejeződik, és az az ügyfél, amely eldobja a válaszlistát, csendes írásműveletté teszi a sikertelen írást. Hasonlítsa össze a válaszlista hosszát a sorba állított parancsok számával.

Tartsa életben a kapcsolatot a műveletek között

Minden új kapcsolat fizet a névfeloldásért, egy TCP-kézfogásért, egy TLS-kézfogásért és egy AUTH-ért, VPN-en pedig ezek mindegyike olyan oda-vissza út, amelyet nem tud kötegelve eltüntetni. Hozza létre az ügyfelet folyamatonként egyszer, és használja újra, vagy használja a könyvtára által kínált, korlátozott méretű poolt. A kérésenkénti újracsatlakozás a parancsonkénti várakozások után a második leggyakoribb oka ennek a tünetnek.

Tartsa a privát gazdanevet a konfigurációban szó szerinti cím helyett. A tanúsítvány-ellenőrzés és a szolgáltatásidentitás privát hálózaton is érvényes, és egy IP rögzítése abban a pillanatban eltörik, amikor a szolgáltató újraszámoz egy alhálózatot. Ha a feloldás a lassú rész, a feloldó útvonalát javítsa, ne a kapcsolati karakterláncot.

Állítson be kifejezett socket-időtúllépést, hogy az elakadt alagút gyorsan meghiúsuljon, ne pedig lógassa a munkást. Ezután erősítse meg, hogy a pool valóban újrahasznosul, ha naplózza a kapcsolatok létrehozását az ügyfélben.

Méretezze a köteget, mielőtt memóriaproblémává válik

A Redis a köteg teljes ideje alatt tárolja a sorba állított válaszokat, az ügyfél pedig utána tárolja az elemzett eredményt. Egy tízezer nagy értékből álló csővezeték hálózati várakozásokat cserél memóriacsúcsokra és hosszú szünetekre mindkét végén.

A kötegméretet a válaszmennyiséghez válassza, ne a parancsszámhoz. Néhány száz kis parancs egy kötegben általában kényelmes, száz többkilobájtos terhelés viszont nem. Ossza bájtok és darabszám szerint is, és tartsa minden köteget a végpont tényleges késleltetési keretén belül.

Mérje meg végponttól végpontig a változtatás után: redis-cli -h redis.example.internal --latency-history megmutatja, hogy maga az út stabil-e, a saját kérésidőmérője pedig azt, hogy javult-e a végpont. Ha a végpont továbbra is lassú, miközben a késleltetési előzmények laposak, a fennmaradó költség kiszolgálóoldali munka vagy a saját szerializálása, és a következő lépés a kezelő profilozása, nem pedig egy újabb kötegelési változtatás.