Redis VPN арқылы баяу көрінеді: сұранысқа шаққанда айналымдарды азайту

Жергілікті Redis-ке қарсы 200 мс ішінде жауап беретін бет, клиент VPN артына отырған бойда төрт секундқа созылады, ал сервер есептегіштері бос тұрады. Баяу журнал бір миллисекундтан жоғары ештеңе көрсетпейді, CPU графигі тегіс, ал дана басқа клиенттерге шағымсыз қызмет етеді. Өзгерген нәрсе — қашықтық, ал қашықтықты көбейтетін нәрсе — кодыңыздың тоқтап күту саны. Сұраныс жолын клиенттен сыртқа қарай жүріп өтіңіз, шешім әдетте жылдамырақ сервер емес, кемірек дәйекті күтулер.

Сервер көрсеткіштерінен емес, клиенттен бастаңыз

Клиент процесін бірінші бұйрық пен соңғы бұйрық арасында бақылаңыз. Егер із жауап, үзіліс, сосын келесі бұйрықты көрсетсе, сіз әр бұйрық үшін толық айналым төлеп жатырсыз және серверді реттеудің ешбір мөлшері мұны өзгертпейді. Баяу журнал мұнда қате құрал, өйткені ол орындалу уақытын тіркейді және байланыс I/O-сын әдейі шығарып тастайды. Баяу соңғы нүктенің қасындағы таза баяу журнал — айналым мәселесінің белгісі.

Кодқа тиіспес бұрын жолдың өзін өлшеңіз. redis-cli -h redis.example.internal --latency қайталамалы PING жіберіп, сұраныс пен жауаптың орташа уақытын шығарады, бұл сіздің бір айырбасқа жұмсайтын шығыныңыз. Оны бір пайдаланушы әрекетіндегі дәйекті бұйрықтар санына көбейтіңіз, соңғы нүкте үшін төменгі шек шығады.

Бір пайдаланушы әрекетіне шынымен қанша айналым қажет екенін санаңыз

Бір соңғы нүктені алып, әр Redis шақыруын ретімен жазыңыз, ORM, сессия аралық бағдарламасы немесе мүмкіндік жалаушасын іздеу ішінде жасырылғандарын қоса. Баяу соңғы нүктелердің көбі үш жететін жерде жиырма немесе отыз шақыру жасайды, ал жасырылғандары әдетте көпшілік.

Тәуелділік тізбегін бүктеуге болмайды: егер екінші бұйрыққа бірінші қайтарған кілт керек болса, күту шынайы және жалғыз нұсқалар — басқа деректер моделі немесе бүкіл қадамды бірден білдіретін сервер жақты операция. Тәуелсіз оқулар басқа жағдай, өйткені екіншісін жіберер алдында бірінші жауапты күтуге ештеңе мәжбүрлемейді. Бірдеңені өңдеудің алдында әр шақыруды тәуелді немесе тәуелсіз деп белгілеңіз, шешімнің пішіні айқын болады.

Маңызды сан — дәйекті күтулер, жалпы бұйрықтар емес. Бір бумадағы отыз бұйрық әлі де бір күтуге тұрады.

Бір-біріне тәуелді емес бұйрықтарды ғана бумаға салыңыз

Құбыр тәуелсіз бұйрықтарды кезекке қойып, жауаптарды ретімен жинайды, N күтуді бірге айналдырады. Клиенттердің көбі мұны бөлек қосылым режимі ретінде емес, блок, кері шақыру немесе контекст менеджері ретінде ұсынады, сондықтан орнатылған нұсқаңыз беретін API-ді тексеріңіз. Пайда айналым уақытымен өседі, дәл сондықтан VPN-де маңызды және 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())

Тек бумалау керек болса transaction=False беріңіз. Әдепкіде клиент буманы MULTI мен EXEC ішіне орайды, бұл оны атомды етеді және басқа клиенттердің ұшу барысында нені байқай алатынын өзгертеді. Атомдылық — дұрыстық шешімі, өнімділік тетігі емес, ал құбыр транзакция емес, тек екеуі де айналымдарды азайтатындықтан.

Тек бума жіберуді емес, әр жауапты оқыңыз. Кезектегі бұйрық бума тұтастай аяқталғанша қате қайтаруы мүмкін, ал жауаптар тізімін тастайтын клиент сәтсіз жазуды үнсіз жазбаға айналдырады. Жауаптар тізімінің ұзындығын кезекке қойған бұйрықтар санымен салыстырыңыз.

Әрекеттер арасында қосылымды тірі ұстаңыз

Әр жаңа қосылым атауды шешуге, TCP қол алысуға, TLS қол алысуға және AUTH-қа төлейді, ал VPN арқылы олардың әрқайсысы бумалап кетіре алмайтын айналым. Клиентті әр процесс үшін бір рет жасап, қайта пайдаланыңыз немесе кітапханаңыз ұсынатын шектеулі өлшемді пулды қолданыңыз. Әр сұранысқа қайта қосылу — бұл симптомның бұйрыққа күтуден кейінгі екінші ең жиі себебі.

Конфигурацияда нақты мекенжай емес, жеке хост атын ұстаңыз. Сертификатты тексеру және қызмет сәйкестігі жеке желіде де қолданылады, ал IP-ді бекіту провайдер ішкі желіні қайта нөмірлеген сәтте бұзылады. Егер шешу баяу бөлік болса, қосылым жолын емес, шешуші жолын түзетіңіз.

Айқын сокет күту уақытын орнатыңыз, тығырыққа тірелген туннель жұмысшыны іліп қоюдың орнына тез сәтсіз болсын. Сосын клиентте қосылым жасалуын журналға тіркеп, пул шынымен қайта пайдаланылатынын растаңыз.

Жады мәселесіне айналмай тұрып бума өлшемін анықтаңыз

Redis кезектегі жауаптарды буманың бүкіл ұзақтығында ұстайды, ал клиент кейін талданған нәтижені ұстайды. Он мың үлкен мәннен тұратын құбыр желілік күтулерді жады секірулерімен және екі ұшында ұзақ үзілістермен айырбастайды.

Бума өлшемін бұйрық санына емес, жауап көлеміне қарай таңдаңыз. Бір бумада бірнеше жүз шағын бұйрық әдетте қолайлы, ал жүз бірнеше килобайттық жүктеме олай емес. Байттар және сан бойынша да бөліңіз, әр буманы соңғы нүктенің нақты кешігу бюджетінің ішінде ұстаңыз.

Өзгерістерден кейін ұштан ұшқа дейін өлшеңіз: redis-cli -h redis.example.internal --latency-history жолдың өзі тұрақты ма екенін көрсетеді, ал өз сұраныс таймеріңіз соңғы нүкте жақсарды ма екенін көрсетеді. Егер кешігу тарихы тегіс болса да соңғы нүкте баяу болса, қалған шығын сервер жақты жұмыс немесе өз сериализацияңыз, ал келесі қадам — тағы бір бума өзгерісі емес, өңдеушінің профилі.