ഉപയോക്താക്കളോ ത്രൂപുട്ടോ? യഥാർത്ഥ ലോഡിനായി VPN സർവർ അളക്കൽ
അക്കൗണ്ട് എണ്ണം ഗേറ്റ്‌വേ അളക്കുന്നില്ല; ഒന്നിനൊന്ന് കവിയുന്ന ജോലിയാണ് അളക്കുന്നത്. സമകാലിക ട്രാൻസ്ഫറുകൾ, കോർ ഓരോന്നിലെ CPU, ക്യൂകൾ എന്നിവ താരതമ്യം ചെയ്ത് ലോഡ് എഴുതുക.
പത്ത് നിഷ്ക്രിയ അക്കൗണ്ടുകൾ ടണൽ നിറയ്ക്കുന്ന ഒരു രാത്രി ബാക്കപ്പിനേക്കാൾ കുറവ് ചെലവാക്കുന്നു, ഉപയോക്തൃ എണ്ണത്തിന് ആ വ്യത്യാസം കാണിക്കാനാവില്ല. VPN സർവർ അളക്കൽ രണ്ട് സംഖ്യകളുടെ താരതമ്യമാണ്: നിങ്ങൾ യഥാർത്ഥത്തിൽ വഹിക്കുന്ന സമകാലികതയും ആദ്യം തീരുന്ന വിഭവവും. മിക്ക കപ്പാസിറ്റി പിഴവുകളും ആദ്യ സംഖ്യ തിരഞ്ഞെടുത്ത് രണ്ടാമത്തേത് ഒരിക്കലും അളക്കാതിരിക്കുന്നതിൽ നിന്നാണ്. രണ്ടും ഈ ക്രമത്തിൽ ചെയ്യുക, ഹാർഡ്‌വെയർ തീരുമാനം ഊഹമല്ലാതാകും.
അക്കൗണ്ടുകളുടെ എണ്ണം തിരക്കുള്ള മണിക്കൂറുമായി താരതമ്യം ചെയ്യുക
അക്കൗണ്ട് എണ്ണം ലൈസൻസും പിന്തുണാ പരിധിയുമാണ്; തിരക്കുള്ള മണിക്കൂർ ഒരു ലോഡാണ്. ആ മണിക്കൂറിൽ ഒന്നിനൊന്ന് കവിയുന്ന ജോലികൾ ലിസ്റ്റ് ചെയ്യുക: കോളുകൾ, ദൂര നിയന്ത്രണം, വലിയ ഡൗൺലോഡുകൾ, ബാക്കപ്പുകൾ, ആളുകളെ കാത്തിരിക്കുന്ന സ്വകാര്യ അപ്ലിക്കേഷൻ അഭ്യർത്ഥനകൾ. ഓരോ ഇനത്തിനും അത് ഗേറ്റ്‌വേ കടക്കുന്നുണ്ടോ, ഏത് ദിശയിലാണ് എന്ന് അടയാളപ്പെടുത്തുക. കോളുകൾ സമമിതവും കാലതാമസത്തോട് സംവേദവുമാണ്, എന്നാൽ ബാക്കപ്പ് ഒരു ദിശയിലാണ്, പതുക്കെയുള്ള തുടക്കം സഹിക്കുന്നു, അതിനാൽ അവ പാതയുടെ വ്യത്യസ്ത ഭാഗങ്ങളിൽ സമ്മർദ്ദം ചെലുത്തുന്നു.
ദിശ ഏത് ലിങ്ക് പ്രധാനമെന്ന് തീരുമാനിക്കുന്നു. വീട്ടിലെ അപ്‌ലിങ്ക് അപൂർവമായേ സമമിതമാകൂ, ദിവസം മുഴുവൻ ഡൗൺലോഡ് ചെയ്യുന്ന ശാഖ ഗേറ്റ്‌വേ വിയർക്കുന്നതിന് വളരെ മുൻപേ തന്റെ താഴേക്കുള്ള പരിധിയിൽ എത്തുന്നു. ഓരോ ഇനത്തിനും അടുത്ത് ദിശയും ടണലിന്റെ പരിധിയും എഴുതുക, കാരണം സ്വകാര്യ ലക്ഷ്യസ്ഥാനങ്ങൾ മാത്രം വഹിക്കുന്ന ഗേറ്റ്‌വേയും മുഴുവൻ ഇന്റർനെറ്റ് ട്രാഫിക്കും വഹിക്കുന്നതും രണ്ട് വ്യത്യസ്ത അളവെടുപ്പ് പ്രശ്നങ്ങളാണ്.
പശ്ചാത്തല ലോഡ് സ്വന്തം വരിയായി ചേർക്കുക: ക്ലയന്റ് അപ്‌ഡേറ്റുകൾ, ടെലിമെട്രി, ഫോർവേഡിംഗിന് പുറമേ ഹോസ്റ്റ് ചെയ്യുന്നതെല്ലാം. ഈ ബൈറ്റുകൾ മറക്കാൻ എളുപ്പമാണ്, അവ ഒരേ ഇന്റർഫേസാണ് എണ്ണുന്നത്.
ലിങ്കിന് മുൻപേ തീരുന്ന വിഭവം കണ്ടെത്തുക
ലിങ്ക് ഒരു സ്ഥാനാർത്ഥി മാത്രമാണ്. ഒരു ടണലിന്റെ ക്രിപ്റ്റോ ജോലി ഒരു കോർ പിടിച്ചിരിക്കുമ്പോൾ ഇന്റർഫേസ് പകുതി ഒഴിഞ്ഞിരിക്കാം, നിറഞ്ഞ ക്യൂ ഗ്രാഫിൽ സാധാരണമായി തോന്നുന്ന ത്രൂപുട്ടിൽ കോളുകളെ ഉപയോഗശൂന്യമാക്കാം. ഒരു പതുക്കെയുള്ള റൂട്ട് ദൂരത്തിലുള്ള ലക്ഷ്യസ്ഥാനവും ക്ലയന്റിന്റെ ഇരിപ്പിടത്തിൽ നിന്ന് ഗേറ്റ്‌വേയുടെ ബലഹീനതയായി തോന്നാം. മൂന്ന് നിരീക്ഷണങ്ങൾ ഈ കേസുകളെ വേർതിരിക്കുന്നു, ഒന്നിനും സ്ഫോടന പരിശോധന ആവശ്യമില്ല.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
നിങ്ങൾക്ക് അനുവദിച്ച ട്രാൻസ്ഫർ ഉപയോഗിച്ച് അളക്കുക, സമകാലിക ജോലി ഒരുമിച്ചല്ല, ഘട്ടങ്ങളായി ചേർക്കുക. സ്ഥിരമായ നിരക്കും സംവേദനാത്മക പ്രതികരണവും ഒരുമിച്ച് വായിക്കുക, കാരണം പരമാവധി നിരക്ക് മാത്രമുള്ള പരിശോധന ഉപയോഗശൂന്യമായ സെഷൻ മറയ്ക്കുന്നു. കോളുകൾ പൊട്ടുമ്പോൾ പരമാവധി ത്രൂപുട്ട് കടക്കുന്ന ഗേറ്റ്‌വേ പരിശോധന പാസായിട്ടില്ല.
പിന്നീട് ഓപ്ഷണൽ ലോഡുകൾ നിർത്തി അതേ ഓട്ടം ആവർത്തിക്കുക. ബാക്കപ്പ് നിൽക്കുമ്പോൾ നീങ്ങുന്ന പരിധി ഒരിക്കലും ഗേറ്റ്‌വേയുടെ പരിധിയായിരുന്നില്ല.
താരതമ്യത്തെ നിങ്ങൾക്ക് സമർത്ഥിക്കാവുന്ന സംഖ്യയാക്കുക
തീർന്ന വിഭവം തിരഞ്ഞെടുത്ത് ആവശ്യകത അതിന്റെ യൂണിറ്റുകളിൽ പ്രകടിപ്പിക്കുക: തിരക്കുള്ള മണിക്കൂറിൽ ലക്ഷ്യ ഉപയോഗത്തിൽ കോറുകൾ, ഓരോ ദിശയിലും സെക്കൻഡിൽ ബിറ്റുകൾ, അല്ലെങ്കിൽ കാലതാമസ പരിധിക്ക് താഴെ സമകാലിക സെഷനുകൾ. അപ്‌ഡേറ്റുകൾക്കും രോഗനിർണയത്തിനും വീണ്ടെടുപ്പിനും ഇടം വിടുക, കാരണം അളന്ന പരിധിയിൽ ഇരിക്കുന്ന സർവറിന് അതിനെ പ്രവർത്തിപ്പിക്കുന്ന ജോലിക്ക് ഒന്നും ബാക്കിയില്ല. പിന്നീട് സംഖ്യകൾ അവ ഉണ്ടാക്കിയ കോൺഫിഗറേഷന് അടുത്ത് എഴുതുക, ക്ലയന്റ് എണ്ണവും ഉപയോഗിച്ച പരിശോധനയും ഉൾപ്പെടെ.
ഓരോ കോറിനും ഉള്ള ഉപയോക്തൃ സംഖ്യ ഈ വ്യായാമത്തിലെ ഏറ്റവും കുറഞ്ഞ കൈമാറ്റയോഗ്യ സംഖ്യയാണ്, കാരണം അടുത്ത സൈറ്റ് പങ്കിടാത്ത പ്രോട്ടോക്കോൾ മിശ്രിതവും ഉപകരണ പ്രൊഫൈലും അത് അനുമാനിക്കുന്നു. അളവ് സൂക്ഷിക്കുക, സൂത്രവാക്യം ഉപേക്ഷിക്കുക. ആരെങ്കിലും അമ്പത് അധിക ഉപയോക്താക്കൾക്ക് കപ്പാസിറ്റി ചോദിച്ചാൽ, സത്യസന്ധമായ ഉത്തരം ആ അമ്പതിന്റെ തിരക്കുള്ള മണിക്കൂർ പ്രൊഫൈലാണ്, ഗുണനമല്ല.
ത്രൂപുട്ടിനൊപ്പം പ്രതികരണ സമയവും രേഖപ്പെടുത്തുക. വലിയ തോതിലുള്ള ട്രാൻസ്ഫർ മാത്രം സംരക്ഷിക്കുന്ന കപ്പാസിറ്റി കോളിലുള്ള ആളുകൾക്കുള്ള കപ്പാസിറ്റിയല്ല, അടുത്ത അവലോകനം ഈ വ്യത്യാസം ചോദിക്കും.
മുകളിലേക്ക് സ്കെയിൽ ചെയ്യുന്നതും റോൾ വിഭജിക്കുന്നതും തമ്മിൽ തിരഞ്ഞെടുക്കുക
അളന്ന പരിധി ഒരു കോർ ആണെങ്കിൽ, അതേ വേഗതയിലുള്ള കൂടുതൽ കോറുകൾ സഹായിച്ചെന്ന് വരില്ല; വേഗതയേറിയ കോറോ വ്യത്യസ്ത വർക്കർ മാതൃകയോ സഹായിക്കാം. പരിധി ആകെ CPU ആണെങ്കിൽ, വലിയ ഇൻസ്റ്റൻസ് നേരിട്ടുള്ള പരിഹാരമാണ്. പരിധി ആക്സസ് ലിങ്ക് ആണെങ്കിൽ, സർവർ മാറ്റം സഹായിക്കില്ല, താരതമ്യം ദാതാവിൽ അവസാനിക്കുന്നു. വെബ്, VPN റോളുകൾ വേർതിരിച്ച ഹോസ്റ്റുകളിലേക്ക് വിഭജിക്കുന്നത് രണ്ടാമത്തെ മാനേജ്മെന്റ് ഉപരിതലത്തിന്റെ വിലയ്ക്ക് വേർതിരിവ് വാങ്ങുന്നു.
ആ ഓപ്ഷനുകളെ പരസ്പരമല്ല, രേഖപ്പെടുത്തിയ സംഖ്യയുമായി താരതമ്യം ചെയ്യുക. പരിധിയല്ലാത്ത ഒരു വിഭവം ഇരട്ടിയാക്കുന്ന മാറ്റം നേട്ടമില്ലാത്ത ചെലവാണ്, രേഖ തന്നെയാണ് അത് വാദമില്ലാതെ പറയാൻ നിങ്ങളെ അനുവദിക്കുന്നത്. മാറ്റത്തിന് ശേഷം അതേ ലോഡുമായി വീണ്ടും അളക്കുക, അല്ലെങ്കിൽ ഒരു ഊഹം മറ്റൊന്നുകൊണ്ട് മാറ്റിയിരിക്കുന്നു.