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-ни бекемдөө провайдер ички тармакты кайра номерлеген учурда бузулат. Эгер чечүү жай бөлүк болсо, туташуу сабын эмес, чечүүчүнүн жолун оңдоңуз.

Так socket күтүү убактысын коюңуз, тыгында калган туннель жумушчуну илип коюунун ордуна тез ийгиликсиз болсун. Анан кардарда байланыш түзүлүшүн журналга жазып, пул чынында кайра колдонуларын ырастаңыз.

Эстутум маселесине айланганга чейин топтомдун өлчөмүн аныктаңыз

Redis кезектеги жоопторду топтомдун бүт убактысында кармайт, ал эми кардар кийин талданган натыйжаны кармайт. Он миң чоң мааниден турган куур тармактык күтүүлөрдү эстутум секириктери жана эки учунда узак тыныгуулар менен алмаштырат.

Топтомдун өлчөмүн буйруктардын санына эмес, жооп көлөмүнө карап тандаңыз. Бир топтомдо бир нече жүз кичине буйрук адатта ыңгайлуу, ал эми жүз бир нече килобайттык жүк эмес. Байттар жана сан боюнча да бөлүңүз, ар бир топтомду акыркы чекиттин реалдуу кечигүү бюджетинин ичинде кармаңыз.

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