VPN വഴിയുള്ള Redis മന്ദഗതിയിലെന്ന് തോന്നുന്നു: ഓരോ അഭ്യർത്ഥനയ്ക്കും റൗണ്ട് ട്രിപ്പുകൾ കുറയ്ക്കുക

പ്രാദേശിക 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 പാത തന്നെ സ്ഥിരമാണോ എന്ന് കാണിക്കുന്നു, നിങ്ങളുടെ സ്വന്തം അഭ്യർത്ഥന ടൈമർ എൻഡ്പോയിന്റ് മെച്ചപ്പെട്ടോ എന്ന് കാണിക്കുന്നു. ലേറ്റൻസി ചരിത്രം പരന്നതായിരിക്കുമ്പോഴും എൻഡ്പോയിന്റ് ഇപ്പോഴും മന്ദഗതിയിലാണെങ്കിൽ, ബാക്കിയുള്ള ചെലവ് സർവർ-വശ പ്രവർത്തനമോ നിങ്ങളുടെ സ്വന്തം സീരിയലൈസേഷനോ ആണ്, അടുത്ത ഘട്ടം മറ്റൊരു ബാച്ചിംഗ് മാറ്റമല്ല, ഹാൻഡ്ലറുടെ പ്രൊഫൈൽ ആണ്.