ഒരു സംസാരിക്കുന്ന SQL ആപ്പ് VPN-ലൂടെ എന്തുകൊണ്ട് പതുക്കെയാകുന്നു, എന്താണ് ബാച്ച് ചെയ്യേണ്ടത്

ലോക്കൽ നെറ്റ്വർക്കിൽ ഒരു സെക്കൻഡിൽ കുറവിൽ തുറക്കുന്ന ഒരു ഫോം VPN വഴി അഞ്ച് സെക്കൻഡ് എടുക്കുന്നു, അതേ ലിങ്കിലെ ഫയൽ പകർപ്പ് പൂർണ്ണ വേഗത്തിൽ പോകുന്നു. വ്യത്യാസം ബാൻഡ്വിഡ്ത്തിലല്ല. ഫോം ഉത്തരങ്ങളുടെ ഒരു ശ്രേണിക്കായി കാത്തിരിക്കുകയും ഓരോ ഘട്ടത്തിലും മുഴുവൻ റൗണ്ട് ട്രിപ്പും നൽകുകയും ചെയ്യുന്നു, അതേസമയം ഫയൽ പകർപ്പ് ബൈറ്റുകൾ തുടർച്ചയായി നീക്കത്തിൽ നിർത്തുന്നു. ആക്സസ് ലൈനിൽ തൊടുന്നതിന് മുൻപ് ആ കാത്തിരിപ്പുകൾ എണ്ണുക.

രോഗലക്ഷണം ഒരു സ്ക്രീനാണ്, ഒരു ക്വറിയല്ല

ആ സ്ക്രീനിലെ ഓരോ ക്വറിയും വേഗത്തിലാകാം, സ്ക്രീൻ ഇപ്പോഴും പതുക്കെയാകാം, കാരണം ആകെത്തുക എക്സിക്യൂഷൻ സമയങ്ങളുടെ തുകയല്ല, കാത്തിരിപ്പുകളുടെ തുകയാണ്. രണ്ട് മില്ലിസെക്കൻഡിൽ പ്രവർത്തിക്കുന്ന ഒരു സ്റ്റേറ്റ്മെന്റ് പോലും, അടുത്തത് അയക്കുന്നതിന് മുൻപ് ഫലം സ്വീകരിക്കണമെങ്കിൽ ഒരു മുഴുവൻ റൗണ്ട് ട്രിപ്പ് ചെലവാക്കുന്നു. നാൽപ്പത് മില്ലിസെക്കൻഡ് ലേറ്റൻസിയുള്ള ഒരു പാതയിൽ, നൂറ് ആശ്രിത കോളുകൾ ഏതെങ്കിലും റെൻഡറിംഗ് ജോലി തുടങ്ങുന്നതിന് മുൻപ് ഏകദേശം നാല് സെക്കൻഡായി കൂടുന്നു. ഈ അങ്കഗണിതം കാത്തിരിപ്പിന്റെ ഒരു മാതൃകയാണ്, നിങ്ങളുടെ ലിങ്കിന്റെ അളവല്ല.

അതുകൊണ്ടാണ് സ്പീഡ് ടെസ്റ്റ് നിരപരാധിയായി തോന്നുന്നത്. ബൾക്ക് ട്രാൻസ്ഫർ ത്രൂപുട്ട് അളക്കുന്നു, സംസാരിക്കുന്ന ഫോം ലേറ്റൻസി അളക്കുന്നു, ഒരു VPN ഒന്നിൽ മികച്ചതായിരിക്കുകയും മറ്റൊന്നിൽ സാധാരണമായി തുടരുകയും ചെയ്യാം. അതിനാൽ സ്ക്രീൻ രോഗനിർണ്ണയം എന്നത് ലിങ്കിനെയല്ല, സ്ക്രീനിനെ അളക്കുന്നതാണ്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഒരു ഉപയോക്തൃ പ്രവർത്തനത്തിന്റെ തുടക്കം മുതൽ അവസാനം വരെയുള്ള സമയം രേഖപ്പെടുത്തുക. പിന്നീടുള്ള പരിഹാരം ഫലിച്ചോ എന്ന് പറയാൻ കഴിയുന്ന ഏക അടിസ്ഥാനം ആ സംഖ്യയാണ്.

ഒരു ഉപയോക്തൃ പ്രവർത്തനത്തിലെ തുടർച്ചയായ കാത്തിരിപ്പുകൾ എണ്ണുക

ഊഹിക്കുന്നതിന് പകരം ക്ലയന്റിൽ അളവ് ചേർക്കുക. psql-ൽ \timing on ഓരോ സ്റ്റേറ്റ്മെന്റിന്റെയും കഴിഞ്ഞ സമയം അച്ചടിക്കുന്നു, EXPLAIN (ANALYZE, BUFFERS) ആ സമയത്തിൽ എത്ര സർവർ യഥാർത്ഥത്തിൽ ജോലിക്ക് ചെലവാക്കി എന്ന് കാണിക്കുന്നു.

ആ രണ്ട് സംഖ്യകൾ തമ്മിലുള്ള വ്യത്യാസം നിങ്ങളുടെ നെറ്റ്വർക്ക്, ക്ലയന്റ് ചെലവാണ്. ഒരു സ്റ്റേറ്റ്മെന്റ് രണ്ട് മില്ലിസെക്കൻഡിൽ പ്രവർത്തിച്ച് ക്ലയന്റ് അറുപത് രേഖപ്പെടുത്തിയാൽ, ബാക്കി അമ്പത് എട്ട് യാത്രയും പ്രാദേശിക പ്രോസസ്സിംഗും ആണ്, ഏതൊരു ഇൻഡക്സും അവ നീക്കില്ല. സ്ക്രീൻ അയക്കുന്ന ഓരോ സ്റ്റേറ്റ്മെന്റിനും ഈ താരതമ്യം ആവർത്തിച്ച്, എക്സിക്യൂഷൻ സമയങ്ങളല്ല വ്യത്യാസങ്ങൾ കൂട്ടിച്ചേർക്കുക.

ഫലം തുടർച്ചയായ കാത്തിരിപ്പുകളുടെ എണ്ണമായി എഴുതിവയ്ക്കുക. അടുത്ത രണ്ട് ഭാഗങ്ങൾക്ക് കുറയ്ക്കാൻ കഴിയുന്ന അളവ് അതാണ്, തെളിവോടെ വാദിക്കാവുന്ന ഒരു സംഖ്യയാണത്.

സ്വതന്ത്ര കോളുകൾ ബാച്ച് ചെയ്യുക, ആശ്രിതമായവ നിലനിർത്തുക

ഒന്നിന്റെ ഫലം മറ്റൊന്ന് വായിക്കാത്ത രണ്ട് സ്റ്റേറ്റ്മെന്റുകൾ ഒരുമിച്ച് സഞ്ചരിച്ച് ഒരിക്കൽ ശേഖരിക്കപ്പെടാം, അത് രണ്ട് കാത്തിരിപ്പുകളെ ഒന്നാക്കുന്നു. രണ്ടാമത്തേതിന് ആദ്യത്തേതിന്റെ മൂല്യം വേണ്ട രണ്ട് സ്റ്റേറ്റ്മെന്റുകൾക്ക് അത് സാധ്യമല്ല, കാരണം ആശ്രിതത്വം യഥാർത്ഥമാണ്, ബാച്ച് ചെയ്യുന്നത് പ്രോഗ്രാം ചെയ്യുന്നത് മാറ്റും. എന്തെങ്കിലും മാറ്റിയെഴുതുന്നതിന് മുൻപ് കോളുകൾ ആ രണ്ട് കൂമ്പാരങ്ങളായി തരംതിരിക്കുക, ഓരോ കൂമ്പാരത്തിന്റെയും വലിപ്പം എന്ത് സാധ്യമെന്ന് പറയും.

സെറ്റ് അധിഷ്ഠിത ജോലി ബാച്ചിംഗിനെക്കാൾ സമഗ്രമായി കാത്തിരിപ്പുകൾ നീക്കുന്നു. ഒരു ലൂപ്പ് ഒന്നൊന്നായി എടുത്തിരുന്ന വരികൾ തിരികെ നൽകുന്ന ഒരു ക്വറി ലൂപ്പും റൗണ്ട് ട്രിപ്പുകളും ഒരുമിച്ച് ഒഴിവാക്കുന്നു. ആദ്യം ലൂപ്പ് തിരയുക, കാരണം അതാണ് സാധാരണയായി വലിയ നേട്ടവും പരിശോധിക്കാൻ എളുപ്പമുള്ള മാറ്റവും.

ബാച്ച് ഇപ്പോഴും പിശക് കൈകാര്യം ചെയ്യലും ട്രാൻസാക്ഷൻ അതിരുകളും സംരക്ഷിക്കണം. ബന്ധമില്ലാത്ത സ്റ്റേറ്റ്മെന്റുകൾ ഒരൊറ്റ സ്ട്രിംഗായി ചേർക്കുന്നത് സുരക്ഷിതമായ ഒപ്റ്റിമൈസേഷനല്ല, പരാജയപ്പെട്ട സ്റ്റേറ്റ്മെന്റിനെ വിജയകരമായ സമർപ്പണത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്ന ബാച്ച് അത് ലാഭിച്ച കാത്തിരിപ്പുകളെക്കാൾ മോശമാണ്.

ബാൻഡ്വിഡ്ത്ത് വാങ്ങുന്നതിന് മുൻപ് കണക്ഷനുകൾ വീണ്ടും ഉപയോഗിക്കുക

ഒരു പുതിയ കണക്ഷന് നെയിം റെസല്യൂഷൻ, TCP ഹാൻഡ്ഷേക്ക്, TLS ചർച്ചകൾ, പ്രാമാണീകരണം എന്നിവ ചെലവാകുന്നു, ഉയർന്ന ലേറ്റൻസിയുള്ള പാതയിൽ അവ ഓരോന്നും ആദ്യ ക്വറി ഓടുന്നതിന് മുൻപുള്ള മറ്റൊരു റൗണ്ട് ട്രിപ്പാണ്. കണക്ഷൻ പൂളുകൾ ആ ചെലവ് ഓരോ കോളിനും എന്നതിന് പകരം ഓരോ പ്രോസസ്സിനും ഒരിക്കൽ നൽകാൻ ഉള്ളതാണ്.

ADO.NET-ൽ, പൂളിലുള്ള കണക്ഷൻ അടയ്ക്കുകയോ dispose ചെയ്യുകയോ ചെയ്യുമ്പോൾ പുതിയ ഭൗതിക കണക്ഷൻ തുറക്കുന്നതിന് പകരം അത് വീണ്ടും ഉപയോഗത്തിന് തിരികെ നൽകുന്നു, അതിനാൽ ചോർച്ചയായി തോന്നുന്ന മാതൃക പലപ്പോഴും ശരിയായ ഉപയോഗമാണ്. പൂൾ യഥാർത്ഥത്തിൽ ഉപയോഗത്തിലുണ്ടോ എന്ന് ഊഹിക്കാതെ പരിശോധിക്കുക: ഭൗതിക കണക്ഷൻ സൃഷ്ടി ലോഗ് ചെയ്യുക, അല്ലെങ്കിൽ സ്ക്രീൻ ഓടുമ്പോൾ സർവറിലെ സെഷൻ എണ്ണം നിരീക്ഷിക്കുക. SQL പെർഫോമൻസ് മാർഗ്ഗനിർദ്ദേശം റൗണ്ട് ട്രിപ്പുകൾ കുറയ്ക്കുന്നതിനെയും ഇടയ്ക്കിടെയുള്ള ad hoc കോളുകൾ ബാച്ച് ചെയ്യുന്നതിനെയും കുറിച്ച് ഇതേ കാര്യം പറയുന്നു, സേവനത്തിന് പ്രത്യേകമായ ഉദാഹരണങ്ങളോടെ, അവ നിങ്ങളുടെ സ്വന്തം വിന്യാസത്തിന് അനുയോജ്യമാക്കണം.

പൂളിംഗ് സെറ്റപ്പ് ചെലവ് നീക്കുന്നു, തുടർച്ചയായ ക്വറി കാത്തിരിപ്പുകളെ തൊടാതെ വിടുന്നു. അത് സ്വയം ഒരു പരിഹാരമല്ല, വൃത്തിയുള്ള അളവെടുപ്പിനുള്ള മുൻവ്യവസ്ഥയാണ്.

എക്സിക്യൂഷൻ ഡാറ്റയ്ക്ക് അടുത്തേക്ക് മാറ്റുന്നത് തൂക്കിനോക്കുക

ഡാറ്റാബേസിന് അടുത്ത് ആപ്പ് ഓടിക്കുന്നത് പല ദൂര ഡാറ്റാബേസ് കൈമാറ്റങ്ങളെ ഒരു ദൂര ഡിസ്പ്ലേ സെഷൻ കൊണ്ട് മാറ്റുന്നു. സംസാരിക്കുന്ന വർക്കുലോഡിന് അത് വലിയ മാറ്റമാകാം, അത് പ്രകടനത്തിന്റെത്രയും പ്രവർത്തനപരമായ മാറ്റമാണ്: സെഷൻ മാനേജ്മെന്റ്, ആക്സസ് നിയന്ത്രണം, സോഫ്റ്റ്വെയർ വിന്യാസം, ഉപയോക്തൃ അനുഭവം എല്ലാം ആപ്പിനൊപ്പം നീങ്ങുന്നു.

ഏത് ദിശ വേഗത്തിലാണെന്ന് ഊഹിക്കുന്നതിന് മുൻപ് യഥാർത്ഥ ഇന്റർഫേസും അത് കൈമാറുന്ന ഡാറ്റയും അളക്കുക. ഒരു റിമോട്ട് ഡെസ്ക്ടോപ്പ് സെഷൻ പിക്സലുകൾ നീക്കുന്നു, സാന്ദ്രമായ ഗ്രാഫിക്സുള്ള ഒരു സ്ക്രീൻ അതേ പാതയിൽ അത് മാറ്റിയ ക്വറികളെക്കാൾ മോശമായി പ്രവർത്തിക്കാം, പ്രത്യേകിച്ച് ക്ലയന്റ് തുടർച്ചയായി വീണ്ടും വരയ്ക്കുമ്പോൾ.

പിന്നെ യഥാർത്ഥ പ്രവർത്തനം ആവർത്തിച്ച് മൂന്ന് സംഖ്യകൾ താരതമ്യം ചെയ്യുക: തുടർച്ചയായ കാത്തിരിപ്പുകൾ, ഫലത്തിന്റെ അളവ്, തുടക്കം മുതൽ അവസാനം വരെയുള്ള പൂർത്തീകരണ സമയം. ഡാറ്റയുടെ കൃത്യതയും ആക്സസ് നയവും സംരക്ഷിച്ചുകൊണ്ട് അളന്ന ഉപയോക്തൃ ജോലിയെ മെച്ചപ്പെടുത്തുന്ന മാറ്റമാണ് നിലനിർത്താൻ യോഗ്യമായത്.