Redis dros VPN yn teimlo'n araf: llai o daith gron fesul cais

Mae tudalen sy'n ateb mewn 200 ms yn erbyn Redis lleol yn cymryd pedair eiliad pan eistedd y cleient y tu ôl i VPN, tra bo chwilwyr y gweinydd yn segur. Nid yw'r log araf yn dangos dim uwchben miliseg, mae'r graff CPU yn wastad, ac mae'r enghraifft yn gwasanaethu cleientiaid eraill heb gŵyn. Yr hyn sydd wedi newid yw'r pellter, a'r peth sy'n lluosi'r pellter yw nifer y troeon y mae eich cod yn stopio ac yn aros. Cerddwch lwybr y cais o'r cleient tuag allan a'r ateb bron bob tro yw llai o arosiadau dilynol yn hytrach na gweinydd cyflymach.

Dechreuwch o'r cleient, nid o fetrigau'r gweinydd

Gwylwch broses y cleient rhwng y gorchymyn cyntaf a'r olaf. Os yw'r ôl yn dangos ateb, saib, yna'r gorchymyn nesaf, rydych yn talu taith gron lawn am bob gorchymyn ac ni fydd unrhyw faint o diwnio'r gweinydd yn newid hynny. Y log araf yw'r offeryn anghywir yma, oherwydd ei fod yn cofnodi amser gweithredu ac yn eithrio I/O cyfathrebu yn fwriadol. Log araf glân wrth ymyl pen draw araf yw llofnod problem taith gron.

Mesurwch y llwybr ei hun cyn cyffwrdd â chod. Mae redis-cli -h redis.example.internal --latency yn anfon PINGau dro ar ôl tro ac yn argraffu'r amser cais ac ateb cyfartalog, sef eich cost fesul cyfnewid. Lluoswch hynny â nifer y gorchmynion dilynol mewn un weithred defnyddiwr a chewch lawr isaf i'r pen draw.

Cyfrifwch y teithiau crwn y mae un weithred defnyddiwr yn ei hangen mewn gwirionedd

Cymerwch un pen draw ac ysgrifennwch bob galwad Redis mewn trefn, gan gynnwys y rhai sy'n cuddio y tu mewn i ORM, middleware sesiwn neu chwiliad nodwedd. Mae'r rhan fwyaf o bennau draw araf yn gwneud ugain neu dri deg o alwadau lle byddai tri yn ddigon, a'r rhai cudd yw'r mwyafrif fel arfer.

Ni ellir cwympo cadwyn dibyniaeth: os oes angen allwedd a ddychwelwyd gan y cyntaf ar yr ail orchymyn, mae'r aros yn real a'r unig opsiynau yw model data gwahanol neu weithrediad ar y gweinydd sy'n mynegi'r cam cyfan ar unwaith. Mae darlleniadau annibynnol yn achos gwahanol, oherwydd nid oes dim yn eich gorfodi i aros am yr ateb cyntaf cyn anfon yr ail. Marciwch bob galwad fel dibynnol neu annibynnol cyn golygu unrhyw beth, a daw siâp yr ateb yn amlwg.

Y rhif sy'n cyfrif yw arosiadau dilynol, nid cyfanswm y gorchmynion. Mae tri deg o orchmynion mewn un swp yn dal i gostio un aros.

Bwndelwch yn unig y gorchmynion nad ydynt yn dibynnu ar ei gilydd

Mae biblinell yn ciwio gorchmynion annibynnol ac yn casglu'r atebion mewn trefn, gan droi N arosiad yn un. Mae'r rhan fwyaf o gleientiaid yn ei gynnig fel bloc, callback neu reolwr cyd-destun yn hytrach na modd cysylltiad ar wahân, felly gwiriwch yr API y mae'ch fersiwn wedi'i osod yn ei chynnig. Mae'r enillion yn graddio gydag amser taith gron, a dyna'n union pam mae'n bwysig ar VPN ac yn brin o sylw ar 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())

Pasiwch transaction=False pan mai dim ond bwndelu sydd ei angen. Gyda'r rhagosodiad mae'r cleient yn lapio'r swp mewn MULTI ac EXEC, sy'n ei wneud yn atomig ac yn newid yr hyn y gall cleientiaid eraill ei arsylwi yn ystod y daith. Mae atomigrwydd yn benderfyniad cywirdeb yn hytrach na chnob perfformiad, ac nid yw biblinell yn drafodaeth dim ond oherwydd bod y ddau yn lleihau teithiau crwn.

Darllenwch bob ateb yn hytrach na dim ond cyflwyno'r swp. Gall gorchymyn a giwiwyd ddychwelyd gwall tra bo'r swp yn cwblhau'n gyfan, ac mae cleient sy'n taflu'r rhestr atebion yn troi ysgrifennu methiedig yn un distaw. Cymharwch hyd y rhestr atebion â nifer y gorchmynion a giwiwyd gennych.

Cadwch y cysylltiad yn fyw rhwng gweithredoedd

Mae pob cysylltiad newydd yn talu am ddatrys enwau, ysgwyd llaw TCP, ysgwyd llaw TLS ac AUTH, a thros VPN mae pob un o'r rhain yn daith gron na allwch ei bwndelu i ffwrdd. Crëwch y cleient unwaith y broses ac ailddefnyddiwch ef, neu defnyddiwch y pwll y mae'ch llyfrgell yn ei gynnig â maint cyfyngedig. Ailgysylltu fesul cais yw'r ail achos mwyaf cyffredin o'r symptom hwn ar ôl aros fesul gorchymyn.

Cadwch yr enw gwesteiwr preifat yn y ffurfwedd yn hytrach nag adres lythrennol. Mae dilysu tystysgrif a hunaniaeth gwasanaeth yn dal i fod yn berthnasol ar rwydwaith preifat, ac mae pinio IP yn torri'r eiliad y bydd y darparwr yn ailrifo isrwydwaith. Os datrys yw'r rhan araf, trwsiwch lwybr y datryswr yn hytrach na'r llinyn cysylltu.

Gosodwch derfyn amser soced penodol fel bod tiwnel sy'n stelcio yn methu'n gyflym yn hytrach na hongian gweithiwr. Yna cadarnhewch fod y pwll yn cael ei ailddefnyddio mewn gwirionedd drwy gofnodi creu cysylltiadau yn y cleient.

Mesurwch y swp cyn iddo ddod yn broblem cof

Mae Redis yn dal atebion ciwiedig am gyfnod y swp, ac mae'r cleient yn dal y canlyniad a ddadansoddwyd wedyn. Mae biblinell o ddeg mil o werthoedd mawr yn cyfnewid arosiadau rhwydwaith am bigau cof a seibiau hir ar y ddau ben.

Dewiswch faint y swp yn ôl cyfaint yr atebion yn hytrach na nifer y gorchmynion. Mae ychydig gannoedd o orchmynion bach mewn un swp fel arfer yn gyfforddus, tra nad yw cant o lwythi sawl cilobeit felly. Rhannwch yn ôl beitiau yn ogystal ag yn ôl nifer, a chadwch bob swp o fewn y gyllideb oedi sydd gan y pen draw mewn gwirionedd.

Mesurwch o'r dechrau i'r diwedd ar ôl y newid: mae redis-cli -h redis.example.internal --latency-history yn dangos a yw'r llwybr ei hun yn sefydlog, ac mae'ch amservdd cais eich hun yn dangos a wellodd y pen draw. Os yw'r pen draw yn dal yn araf tra bo hanes yr oedi yn wastad, y gost sy'n weddill yw gwaith ar y gweinydd neu'ch cyfresoliad eich hun, a'r cam nesaf yw proffil o'r triniwr yn hytrach na newid bwndelu arall.