Redis VPN:n yli tuntuu hitaalta: vähemmän edestakaisia siirtoja pyyntöä kohden

Sivu, joka vastaa 200 ms:ssa paikallista Redisia vastaan, kestää neljä sekuntia, kun asiakas istuu VPN:n takana, samalla kun palvelimen laskurit seisovat tyhjinä. Hidas loki ei näytä mitään yli millisekunnin, CPU-käyrä on tasainen ja instanssi palvelee muita asiakkaita valittamatta. Muuttunut asia on etäisyys, ja etäisyyttä kertoo niiden kertojen määrä, joilla koodisi pysähtyy ja odottaa. Käy pyynnön polku asiakkaasta ulospäin ja ratkaisu on lähes aina vähemmän peräkkäisiä odotuksia eikä nopeampi palvelin.

Aloita asiakkaasta, älä palvelimen mittareista

Tarkkaile asiakasprosessia ensimmäisen ja viimeisen komennon välillä. Jos jälki näyttää vastauksen, tauon ja sitten seuraavan komennon, maksat täyden edestakaisen siirron jokaista komentoa kohden eikä mikään palvelimen viritys muuta sitä. Hidas loki on tässä väärä työkalu, koska se tallentaa suoritusajan ja jättää viestintä-I/O:n tarkoituksella pois. Puhdas hidas loki hitaan päätepisteen vieressä on edestakaisen siirron ongelman allekirjoitus.

Mittaa itse polku ennen kuin kosket koodiin. redis-cli -h redis.example.internal --latency lähettää toistuvia PINGejä ja tulostaa keskimääräisen pyyntö- ja vastausajan, joka on kustannuksesi vaihtoa kohden. Kerro se yhden käyttäjatoiminnon peräkkäisten komentojen määrällä ja saat päätepisteelle alarajan.

Laske edestakaiset siirrot, jotka yksi käyttäjatoiminto todella tarvitsee

Ota yksi päätepiste ja kirjoita ylös jokainen Redis-kutsu järjestyksessä, mukaan lukien ne, jotka on piilotettu ORM:n, istuntoväliohjelmiston tai ominaisuuslipun haun sisään. Useimmat hitaat päätepisteet tekevät lopulta kaksikymmentä tai kolmekymmentä kutsua siellä, missä kolme riittäisi, ja piilotetut ovat yleensä enemmistö.

Riippuvuusketjua ei voi taittaa: jos toinen komento tarvitsee avaimen, jonka ensimmäinen palauttaa, odotus on todellinen ja ainoat vaihtoehdot ovat toinen tietomalli tai palvelinpuolen toiminto, joka ilmaisee koko vaiheen kerralla. Riippumattomat luvut ovat eri tapaus, koska mikään ei pakota sinua odottamaan ensimmäistä vastausta ennen toisen lähettämistä. Merkitse jokainen kutsu riippuvaiseksi tai riippumattomaksi ennen kuin muutat mitään, ja ratkaisun muoto tulee ilmeiseksi.

Merkitsevä luku on peräkkäiset odotukset, ei komentojen kokonaismäärä. Kolmekymmentä komentoa yhdessä erässä maksaa silti yhden odotuksen.

Kokoa erään vain komennot, jotka eivät riipu toisistaan

Putki laittaa riippumattomat komennot jonoon ja kerää vastaukset järjestyksessä, muuttaen N odotusta yhdeksi. Useimmat asiakkaat tarjoavat sen lohkona, callbackina tai kontekstinhallintana erillisen yhteystilan sijaan, joten tarkista API, jonka asennettu versiosi tarjoaa. Hyöty skaalautuu edestakaisen siirron ajan mukaan, ja juuri siksi se merkitsee VPN:llä ja tuskin tuntuu localhostissa.

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

Anna transaction=False, kun haluat vain eräajon. Oletuksena asiakas käärii erän MULTI:n ja EXEC:n sisään, mikä tekee siitä atomin ja muuttaa sitä, mitä muut asiakkaat voivat havaita lennossa. Atomisuus on oikeellisuuspäätös, ei suorituskyvyn nuppi, eikä putki ole transaktio vain siksi, että molemmat vähentävät edestakaisia siirtoja.

Lue jokainen vastaus eikä vain erän lähetystä. Jonoon laitettu komento voi palauttaa virheen, kun erä kokonaisuutena valmistuu, ja asiakas, joka heittää vastauslistan pois, muuttaa epäonnistuneen kirjoituksen hiljaiseksi. Vertaa vastauslistan pituutta jonoon laittamiesi komentojen määrään.

Pidä yhteys elossa toimintojen välillä

Jokainen uusi yhteys maksaa nimenratkaisun, TCP-kättelyn, TLS-kättelyn ja AUTHin, ja VPN:n yli jokainen niistä on edestakainen siirto, jota et voi eräajaa pois. Luo asiakas kerran prosessia kohden ja käytä sitä uudelleen tai käytä kirjastosi tarjoamaa rajallisen kokoista poolia. Uudelleenyhdistäminen jokaista pyyntöä kohden on tämän oireen toiseksi yleisin syy komentokohtaisten odotusten jälkeen.

Pidä yksityinen isäntänimi asetuksissa kirjaimellisen osoitteen sijaan. Varmennevalvonta ja palvelun identiteetti pätevät edelleen yksityisessä verkossa, ja IP:n kiinnittäminen hajoaa hetkellä, jolla tarjoaja numeroi aliverkon uudelleen. Jos nimenratkaisu on hidas osa, korjaa ratkaisijan polku eikä yhteysmerkkijono.

Aseta selkeä socket-aikakatkaisu, jotta jumissa oleva tunneli epäonnistuu nopeasti eikä jätä työntekijää roikkumaan. Vahvista sitten, että poolia todella käytetään uudelleen kirjaamalla yhteyksien luonti asiakkaassa.

Mitoita erä ennen kuin siitä tulee muistiongelma

Redis pitää jonossa olevat vastaukset koko erän ajan, ja asiakas pitää sen jälkeen jäsennellyn tuloksen. Kymmenen tuhannen suuren arvon putki vaihtaa verkko-odotukset muistipiikkeihin ja pitkiin taukoihin molemmissa päissä.

Valitse eräkoko vastausvolyymin eikä komentomäärän mukaan. Muutama sata pientä komentoa yhdessä erässä on yleensä mukava, mutta sata monen kilotavun kuormaa ei ole. Jaa sekä tavujen että määrän mukaan ja pidä jokainen erä päätepisteen todellisen latenssibudjetin sisällä.

Mittaa päästä päähän muutoksen jälkeen: redis-cli -h redis.example.internal --latency-history näyttää, onko polku itsessään vakaa, ja oma pyyntöajastimesi näyttää, paraniko päätepiste. Jos päätepiste on edelleen hidas latenssihistorian ollessa tasainen, jäljellä oleva kustannus on palvelinpuolen työtä tai omaa sarjoitustasi, ja seuraava askel on käsittelijän profiili eikä uusi erämuutos.