Redis kupitia VPN huonekana polepole: punguza mizunguko kwa kila ombi

Ukurasa unaojibu kwa 200 ms dhidi ya Redis ya ndani huchukua sekunde nne mara tu mteja anapokaa nyuma ya VPN, wakati vihesabu vya seva vinabaki bila kazi. Slow Log haionyeshi kitu chochote zaidi ya millisekunde moja, grafu ya CPU ni tambarare, na instance huhudumia wateja wengine bila malalamiko. Kilichobadilika ni umbali, na kinachozidisha umbali ni idadi ya nyakati ambazo msimbo wako unasimama na kusubiri. Fuata njia ya ombi kutoka kwa mteja kwenda nje na suluhisho karibu kila mara ni kusubiri kwa mfuatano mara chache, sio seva ya haraka zaidi.

Anza kwa mteja, sio kwa vipimo vya seva

Angalia mchakato wa mteja kati ya amri ya kwanza na ya mwisho. Ikiwa ufuatiliaji unaonyesha jibu, kusimama, kisha amri inayofuata, unalipa mzunguko kamili kwa kila amri na hakuna urekebishaji wa seva utakaobadilisha hilo. Slow Log ni chombo kisichofaa hapa, kwa sababu inarekodi muda wa utekelezaji na kwa makusudi haijumuishi I/O ya mawasiliano. Slow Log safi karibu na endpoint ya polepole ni ishara ya tatizo la mizunguko.

Pima njia yenyewe kabla ya kugusa msimbo. redis-cli -h redis.example.internal --latency hutuma PING za mara kwa mara na kuchapisha wastani wa muda wa ombi na jibu, ambao ni gharama yako kwa kila mabadilishano. Zidisha kwa idadi ya amri za mfuatano katika kitendo kimoja cha mtumiaji na unapata kiwango cha chini cha endpoint.

Hesabu mizunguko ambayo kitendo kimoja cha mtumiaji kinahitaji kwa kweli

Chukua endpoint moja na uandike kila mwito wa Redis kwa mpangilio, ikiwa ni pamoja na yale yaliyofichwa ndani ya ORM, session middleware au utafutaji wa feature flag. Endpoint nyingi za polepole hufanya mwito ishirini au thelathini pale matatu yangetosha, na yaliyofichwa kwa kawaida ni wengi.

Mnyororo wa utegemezi hauwezi kukunjwa: ikiwa amri ya pili inahitaji ufunguo uliorejeshwa na ya kwanza, kusubiri ni kweli na chaguo pekee ni modeli tofauti ya data au operesheni ya upande wa seva inayoeleza hatua yote kwa mara moja. Usomaji huru ni kesi tofauti, kwa sababu hakuna kinachokulazimu kusubiri jibu la kwanza kabla ya kutuma la pili. Weka alama kwa kila mwito kama tegemezi au huru kabla ya kuhariri chochote, na umbo la suluhisho linakuwa wazi.

Nambari inayojalisha ni kusubiri kwa mfuatano, sio jumla ya amri. Amri thelathini katika batch moja bado zinagharimu kusubiri moja.

Weka batch tu amri ambazo hazitegemeani

Pipeline hupanga amri huru kwenye foleni na kukusanya majibu kwa mpangilio, na kugeuza kusubiri kwa N kuwa kumoja. Wateja wengi huifichua kama block, callback au context manager badala ya hali tofauti ya muunganisho, kwa hivyo angalia API ambayo toleo lako lililosakinishwa linatoa. Faida huongezeka kwa muda wa mzunguko, ndiyo sababu inajalisha kwenye VPN na haionekani sana kwenye 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())

Pitisha transaction=False wakati unataka batching tu. Kwa chaguo-msingi mteja hufunga batch kwenye MULTI na EXEC, jambo linaloifanya kuwa atomiki na kubadilisha kile wateja wengine wanaona wakati wa kukimbia. Atomiki ni uamuzi wa usahihi, sio kitufe cha utendaji, na pipeline si muamala eti kwa sababu zote mbili zinapunguza mizunguko.

Soma kila jibu badala ya uwasilishaji wa batch tu. Amri iliyo kwenye foleni inaweza kurudisha kosa wakati batch kwa ujumla inakamilika, na mteja anayetupa orodha ya majibu hugeuza uandishi ulioshindwa kuwa wa kimya. Linganisha urefu wa orodha ya majibu na idadi ya amri ulizopanga kwenye foleni.

Weka muunganisho hai kati ya vitendo

Kila muunganisho mpya hulipia utatuzi wa jina, handshake ya TCP, handshake ya TLS na AUTH, na juu ya VPN kila moja ya hizo ni mzunguko ambao hauwezi kuubatch. Unda mteja mara moja kwa kila mchakato na utumie tena, au tumia pool ambayo maktaba yako inatoa kwa ukubwa uliopunguzwa. Kuunganisha tena kwa kila ombi ni sababu ya pili inayojulikana zaidi ya dalili hii baada ya kusubiri kwa kila amri.

Weka hostname ya kibinafsi kwenye usanidi badala ya anwani halisi. Uthibitishaji wa cheti na utambulisho wa huduma bado unatumika kwenye mtandao wa kibinafsi, na kubandika IP huvunjika mara moja mtoa huduma anapobadilisha nambari za subnet. Ikiwa utatuzi wa jina ni sehemu ya polepole, rekebisha njia ya resolver badala ya mfuatano wa muunganisho.

Weka socket timeout ya wazi ili handaki lililokwama lishindwe haraka badala ya kuning'iniza worker. Kisha thibitisha kwamba pool inatumika tena kwa kuandika kumbukumbu ya uundaji wa muunganisho kwenye mteja.

Pima ukubwa wa batch kabla haujakuwa tatizo la kumbukumbu

Redis hushikilia majibu yaliyopangwa kwenye foleni kwa muda wote wa batch, na mteja hushikilia matokeo yaliyochanganuliwa baadaye. Pipeline ya maelfu kumi ya thamani kubwa hubadilisha kusubiri kwa mtandao na kupanda kwa kumbukumbu na kusimama kwa muda mrefu pande zote mbili.

Chagua ukubwa wa batch kulingana na kiasi cha majibu badala ya idadi ya amri. Amri mia chache ndogo katika batch moja kwa kawaida ni starehe, wakati payload mia za kilobyte nyingi sivyo. Gawanya kwa bytes na kwa idadi, na weka kila batch ndani ya bajeti ya latency ambayo endpoint inayo kwa kweli.

Pima mwanzo hadi mwisho baada ya mabadiliko: redis-cli -h redis.example.internal --latency-history huonyesha kama njia yenyewe ni thabiti, na kipima muda chako cha ombi huonyesha kama endpoint imeboreka. Ikiwa endpoint bado ni polepole wakati historia ya latency ni tambarare, gharama iliyobaki ni kazi ya upande wa seva au usanifu wako, na hatua inayofuata ni profile ya handler badala ya mabadiliko mengine ya batch.