Redis د VPN له لارې ورو ښکاري: په هر غوښتنه کې د تګ راتګ کموول

هغه پاڼه چې د سیمه ییز Redis پر وړاندې په 200 ms ځواب ورکوي، کله چې کلینټ د 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 ښیي چې لاره پخپله ثابته ده که نه، او ستاسو خپل غوښتنې ټایمر ښیي چې پای ټکی ښه شوی که نه۔ که د ځنډ تاریخ هوار وي او پای ټکی لا هم ورو وي، پاتې لګښت د سرور خوا کار یا ستاسو خپل سیریل کول دي، او بله ګام بل ټولګه بدلون نه، بلکې د مدیریت کوونکي پروفایل دی۔