VPN හරහා Redis මන්දගාමී ලෙස දැනේ: ඉල්ලීමකට යන-එන ගමන් අඩු කරන්න

දේශීය Redis එකකට එරෙහිව 200 ms කින් පිළිතුරු දෙන පිටුවක්, සේවාලාභියා VPN එකක් පිටුපස සිටින විට තත්පර හතරක් ගනී, නමුත් සේවාදායකයේ ගණක නිශ්චලව පවතී. Slow Log එකේ මිලි තත්පරයකට වඩා කිසිවක් නොපෙනේ, CPU රූප සටහන පැතලි ය, අවස්ථාව වෙනත් සේවාලාභීන්ට පැමිණිල්ලකින් තොරව සේවය කරයි. වෙනස් වූයේ දුරය, දුර ගුණ කරන දේ නම් ඔබේ කේතය නතර වී රැඳී සිටින වාර ගණනයි. ඉල්ලීමේ මාර්ගය සේවාලාභියාගෙන් පිටතට ගමන් කරන්න; නිවැරදි කිරීම සෑම විටම පාහේ වේගවත් සේවාදායකයක් නොව, අඩු එකින් එක රැඳීම් ය.

සේවාදායකයේ මිනුම්වලින් නොව සේවාලාභියාගෙන් පටන් ගන්න

පළමු විධානය සහ අවසාන විධානය අතර සේවාලාභී ක්‍රියාවලිය දෙස බලන්න. සලකුණු විස්තරයේ පිළිතුරක්, විරාමයක්, පසුව ඊළඟ විධානය පෙනේ නම්, ඔබ සෑම විධානයකටම සම්පූර්ණ යන-එන ගමනක් ගෙවන අතර කිසිදු සේවාදායක සීරුමාරුවක් එය වෙනස් නොකරයි. Slow Log මෙහි වැරදි උපකරණයකි, මන්ද එය ක්‍රියාත්මක වන කාලය සටහන් කරන අතර සන්නිවේදන I/O හිතාමතාම බැහැර කරයි. මන්දගාමී endpoint එකක් අසල පිරිසිදු Slow Log එකක් යන-එන ගැටලුවේ ලකුණයි.

කේතයට අත් නොගෙන මුලින්ම මාර්ගය මැන බලන්න. redis-cli -h redis.example.internal --latency නැවත නැවත PING යවා ඉල්ලීම සහ පිළිතුරේ සාමාන්‍ය කාලය මුද්‍රණය කරයි; එය ඔබේ එක් හුවමාරුවක පිරිවැයයි. එය එක් පරිශීලක කාර්යයක ඇති අනුක්‍රමික විධාන ගණනින් ගුණ කරන්න, එවිට endpoint එකට පහළ මට්ටමක් ලැබේ.

එක් පරිශීලක කාර්යයකට සැබවින්ම අවශ්‍ය යන-එන ගමන් ගණන් කරන්න

එක් endpoint එකක් ගෙන සෑම Redis ඇමතුමක්ම පිළිවෙළින් ලියන්න; ORM එකක්, session middleware එකක් හෝ feature flag සෙවීමක් තුළ සැඟවුණු ඒවා ද ඇතුළත් කරන්න. බොහෝ මන්දගාමී endpoint තුනක් ප්‍රමාණවත් වන තැන විස්සක් හෝ තිහක් ඇමතුම් කරන අතර, සැඟවුණු ඒවා සාමාන්‍යයෙන් බහුතරයයි.

යැපීම් දාමයක් එකට හකුළුවා දැමිය නොහැක: දෙවන විධානයට පළමුවැන්න ආපසු දුන් යතුර අවශ්‍ය නම්, රැඳීම සැබෑ ය, එකම විකල්ප වන්නේ වෙනත් දත්ත ආකෘතියක් හෝ මුළු පියවරම එකවර ප්‍රකාශ කරන සේවාදායක පැත්තේ ක්‍රියාවකි. ස්වාධීන කියවීම් වෙනස් අවස්ථාවකි, මන්ද දෙවැන්න යැවීමට පෙර පළමු පිළිතුර එනතුරු රැඳී සිටින්නට කිසිවක් ඔබට බල නොකරයි. කිසිවක් සංස්කරණය කිරීමට පෙර සෑම ඇමතුමක්ම යැපෙන හෝ ස්වාධීන ලෙස සලකුණු කරන්න, නිවැරදි කිරීමේ හැඩය පැහැදිලි වේ.

වැදගත් වන්නේ අනුක්‍රමික රැඳීම් ගණන, මුළු විධාන ගණන නොවේ. එක් batch එකක තිහක් විධාන තවමත් එක් රැඳීමක් පමණක් වැය කරයි.

එකිනෙකට යැපෙන්නේ නැති විධාන පමණක් batch කරන්න

Pipeline එකක් ස්වාධීන විධාන පෝලිමට දමා පිළිතුරු පිළිවෙළින් එකතු කරයි, N රැඳීම් එකක් බවට හරවයි. බොහෝ සේවාලාභීන් එය වෙනම සම්බන්ධතා මාදිලියක් ලෙස නොව, block එකක්, callback එකක් හෝ context manager එකක් ලෙස ලබා දෙයි, එබැවින් ඔබ ස්ථාපනය කළ සංස්කරණය සපයන 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())

ඔබට අවශ්‍ය වන්නේ batching පමණක් නම් transaction=False ලබා දෙන්න. පෙරනිමිය සමඟ සේවාලාභියා batch එක MULTI සහ EXEC තුළ ඔතයි, එය එය පරමාණුක කරන අතර අනෙක් සේවාලාභීන්ට ගමන් මඟදී දිස්වන දේ වෙනස් කරයි. පරමාණුකත්වය යනු නිරවද්‍යතාව පිළිබඳ තීරණයක් මිස කාර්ය සාධන බොත්තමක් නොවේ, දෙකම යන-එන ගමන් අඩු කරන නිසාම pipeline එකක් ගනුදෙනුවක් නොවේ.

එක් batch එකක් යැවීම පමණක් නොව සෑම පිළිතුරක්ම කියවන්න. පෝලිමේ ඇති විධානයක් මුළු batch එකම සම්පූර්ණ වන අතරතුර දෝෂයක් ආපසු දිය හැක, පිළිතුරු ලැයිස්තුව ඉවත දමන සේවාලාභියෙක් අසාර්ථක ලිවීමක් නිහඬ ලිවීමක් බවට හරවයි. පිළිතුරු ලැයිස්තුවේ දිග ඔබ පෝලිමට දැමූ විධාන ගණන සමඟ සසඳන්න.

ක්‍රියා අතර සම්බන්ධතාව ජීවමානව තබන්න

සෑම නව සම්බන්ධතාවක්ම නම විසඳීම, TCP handshake එකක්, TLS handshake එකක් සහ AUTH එකක් සඳහා ගෙවයි, VPN එකක් මත ඒ සෑම එකක්ම ඔබට batch කළ නොහැකි යන-එන ගමනකි. සේවාලාභියා එක් වරක් ක්‍රියාවලියකට සාදා නැවත භාවිත කරන්න, නැතහොත් ඔබේ පුස්තකාලය සපයන pool එක සීමිත ප්‍රමාණයකින් භාවිත කරන්න. ඉල්ලීමකට නැවත සම්බන්ධ වීම, විධානයකට රැඳීමට පසුව මෙම ලක්ෂණයේ දෙවන වඩාත් පොදු හේතුවයි.

පෞද්ගලික hostname එක වචනාර්ථ ලිපිනයක් ලෙස නොව වින්‍යාසයේ තබන්න. සහතික තහවුරු කිරීම සහ සේවා අනන්‍යතාව පෞද්ගලික ජාලයකද අදාළ වේ, IP එකක් ඇමිණීම සේවා සපයන්නා subnet එකක් නැවත අංකනය කරන මොහොතේම කැඩී යයි. මන්දගාමී කොටස නම විසඳීම නම්, සම්බන්ධතා තන්තුව නොව resolver මාර්ගය නිවැරදි කරන්න.

සිරවූ උමං මාර්ගයක් worker එකක් එල්ලා නොතබා වේගයෙන් අසාර්ථක වන පරිදි පැහැදිලි socket timeout එකක් සකසන්න. පසුව සේවාලාභියා තුළ සම්බන්ධතා නිර්මාණය සටහන් කර pool එක සැබවින්ම නැවත භාවිත වන බව තහවුරු කරන්න.

batch එක මතක ගැටලුවක් වීමට පෙර එහි ප්‍රමාණය තීරණය කරන්න

Redis batch එකේ මුළු කාලය තුළ පෝලිම් කළ පිළිතුරු රඳවා ගනී, පසුව සේවාලාභියා විග්‍රහ කළ ප්‍රතිඵලය රඳවා ගනී. දස දහසක් විශාල අගයන් සහිත pipeline එකක් ජාල රැඳීම් වෙනුවට මතක ඉහළ යාම් සහ දෙකෙළවරම දිගු විරාම ලබා දෙයි.

batch ප්‍රමාණය විධාන ගණන අනුව නොව පිළිතුරු ප්‍රමාණය අනුව තෝරන්න. එක් batch එකක කුඩා විධාන සිය ගණනක් සාමාන්‍යයෙන් පහසු ය, නමුත් කිලෝබයිට් කිහිපයක payload සියයක් එසේ නොවේ. බයිට් අනුව මෙන්ම ගණන අනුවද බෙදන්න, සහ සෑම batch එකක්ම endpoint එකට සැබවින්ම ඇති ප්‍රමාද අයවැය තුළ තබන්න.

වෙනසෙන් පසුව මුල සිට අග දක්වා මනින්න: redis-cli -h redis.example.internal --latency-history මාර්ගයම ස්ථාවරද යන්න පෙන්වයි, ඔබේම ඉල්ලීම් කාලකරුව endpoint එක දියුණු වුණාද යන්න පෙන්වයි. endpoint තවමත් මන්දගාමී වන අතර ප්‍රමාද ඉතිහාසය පැතලි නම්, ඉතිරි පිරිවැය සේවාදායක පැත්තේ වැඩ හෝ ඔබේම serialization වේ, ඊළඟ පියවර තවත් batch වෙනසක් නොව handler එකේ profile එකකි.