VPN-ээр Redis удаан мэт санагдана: нэг хүсэлтэд хийх тойролтыг багасгах

Орон нутгийн 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 зам өөрөө тогтвортой эсэхийг харуулж, өөрийн хүсэлтийн таймер төгсгөлийн цэг сайжирсан эсэхийг харуулна. Хоцролтын түүх тэгш байхад төгсгөлийн цэг удаан хэвээр байвал үлдсэн зардал нь серверийн талын ажил эсвэл өөрийн сериалчлал бөгөөд дараагийн алхам нь өөр нэг багцлах өөрчлөлт биш, боловсруулагчийн профайл юм.