Redis yfir VPN virðist hægt: færri ferðir fram og til baka á hverja beiðni
VPN gerir ekki fjarlægt Redis-kall að staðbundnu. Áætlaðu ferðir fram og til baka á hverja beiðni, endurnýttu tengingar og haltu pípum frá færslum.
Síða sem svarar á 200 ms gegn staðbundnu Redis tekur fjórar sekúndur um leið og biðlarinn situr bak við VPN, á meðan teljarar þjónsins standa aðgerðalausir. Hæga skráin sýnir ekkert yfir millisekúndu, CPU-grafið er flatt og tilvikið þjónar öðrum biðlarum án kvartana. Það sem breyttist er fjarlægðin, og það sem margfaldar fjarlægðina er fjöldi skipta sem kóðinn þinn stöðvast og bíður. Gakktu feril beiðninnar frá biðlaranum út og lausnin er næstum alltaf færri samhliða biðir frekar en hraðari þjónn.
Byrjaðu á biðlaranum, ekki á mælikvörðum þjónsins
Fylgstu með ferli biðlarans milli fyrstu og síðustu skipunar. Ef rakningin sýnir svar, hlé og svo næstu skipun ertu að borga fulla ferð fram og til baka fyrir hverja skipun og engin stilling þjónsins breytir því. Hæga skráin er rangt tæki hér, því hún skráir keyrslutíma og útilokar samskipta-I/O viljandi. Hrein hæg skrá við hlið hægs endapunkts er undirskrift vandamáls með ferðir fram og til baka.
Mældu ferilinn sjálfan áður en þú snertir kóða. redis-cli -h redis.example.internal --latency sendir endurtekin PING og prentar meðaltíma beiðni og svars, sem er kostnaður þinn á hverja skipti. Margfaldaðu það með fjölda samhliða skipana í einni notendaaðgerð og þú hefur lágmark fyrir endapunktinn.
Teldu ferðirnar fram og til baka sem ein notendaaðgerð þarf í raun
Taktu einn endapunkt og skrifaðu niður hvert Redis-kall í röð, þar á meðal þau sem eru falin inni í ORM, setumiðlara eða leit að eiginleikafána. Flestir hægir endapunktar gera tvítug eða þrjátíu köll þar sem þrjú myndu duga, og þau falnu eru yfirleitt meirihlutinn.
Ekki er hægt að brjóta saman áhættukeðju: ef önnur skipunin þarf lykilinn sem fyrsta skilar er biðin raunveruleg og einu valkostirnir eru annað gagnamódel eða þjónshliðaraðgerð sem tjáir allt skrefið í einu. Sjálfstæðar lestrar eru annað tilvik, því ekkert neyðir þig til að bíða eftir fyrra svarinu áður en þú sendir hið síðara. Merktu hvert kall sem háð eða sjálfstætt áður en þú breytir nokkru, og lögun lausnarinnar verður augljós.
Talan sem skiptir máli eru samhliða biðir, ekki heildarskipanir. Þrjátíu skipanir í einum hópi kosta samt eina bið.
Hópaðu aðeins skipanirnar sem eru ekki háðar hver annarri
Pípa setur sjálfstæðar skipanir í biðröð og safnar svörunum í röð og gerir N biðir að einni. Flestir biðlarar bjóða hana sem blokk, afturkall eða samhengisstjóra frekar en sérstakt tengingarham, svo skoðaðu API-ið sem uppsetta útgáfan þín býður. Ávinningurinn stækkar með tíma ferðarinnar, og einmitt þess vegna skiptir hún máli á VPN og er varla merkjanleg á 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())
Sendu transaction=False þegar þú vilt aðeins hópa. Sjálfgefið vefur biðlarinn hópinn í MULTI og EXEC, sem gerir hann atómskan og breytir því hvað aðrir biðlarar geta séð á meðan. Atómska er ákvörðun um réttmæti, ekki afkastahnappur, og pípa er ekki færsla bara af því að bæði fækka ferðum fram og til baka.
Lestu hvert svar í stað þess að senda aðeins hópinn. Skipun í biðröð getur skilað villu á meðan hópurinn klárast í heild, og biðlari sem hendir svaralistanum gerir mistekna skrift að hljóðri. Berðu lengd svaralistans saman við fjölda skipana sem þú settir í biðröð.
Haltu tengingunni lifandi milli aðgerða
Sérhver ný tenging borgar fyrir nafnupplausn, TCP-handaband, TLS-handaband og AUTH, og yfir VPN er hvert þeirra ferð sem þú getur ekki hópað burt. Búðu til biðlarann einu sinni á hvert ferli og endurnýttu hann, eða notaðu laugina sem bókasafnið þitt býður með takmörkuðu stærð. Endurtenging á hverja beiðni er næstalgengasta orsök þessara einkenna á eftir biðum á hverja skipun.
Haltu einkahýsilnafninu í stillingunum frekar en bókstaflegu vistfangi. Vottorðasannprófun og þjónustusjálfsmynd gilda enn á einkaneti, og festing IP brotnar á þeirri stundu sem veitandinn endurnúmerar undirnet. Ef upplausnin er hægi hlutinn skaltu laga slóð leysisins frekar en tengistrenginn.
Stilltu skýran socket-tímamörk svo stíflað göng mistakist fljótt í stað þess að hengja starfsmann. Staðfestu síðan að laugin sé raunverulega endurnýtt með því að skrá tengingarsköpun í biðlaranum.
Stærðu hópinn áður en hann verður minnisvandamál
Redis heldur biðröðuðum svörum í alla tíð hópsins, og biðlarinn heldur síðan greindu niðurstöðunni. Pípa með tíu þúsund stórum gildum skiptir netbiðum út fyrir minnistoppa og löng hlé á báðum endum.
Veldu stærð hópsins eftir magni svara frekar en fjölda skipana. Nokkur hundruð litlar skipanir í einum hópi eru yfirleitt þægilegar, en hundrað margra kílóbæta hleðslur ekki. Skiptu eftir bætum jafnt sem fjölda, og haltu hverjum hópi innan þess biðtímafjárhags sem endapunkturinn hefur í raun.
Mældu frá enda til enda eftir breytinguna: redis-cli -h redis.example.internal --latency-history sýnir hvort ferillinn sjálfur sé stöðugur, og þinn eigin beiðnatímateljari sýnir hvort endapunkturinn batnaði. Ef endapunkturinn er enn hægur á meðan biðtímasagan er flöt er afgangskostnaðurinn þjónshliðarvinna eða eigin raðgreining þín, og næsta skref er prófíll af handfaranum frekar en önnur hópabreyting.