દસ નિષ્ક્રિય ખાતાં એક રાત્રિના બેકઅપ કરતાં ઓછું ખર્ચે છે, જે બેકઅપ ટનલને ભરી દે છે, અને વપરાશકર્તાઓની સંખ્યા આ ફરક બતાવી શકતી નથી. VPN સર્વરનું માપન બે સંખ્યાઓ વચ્ચેની તુલના છે: તમે ખરેખર જે સમવર્તીતા વહન કરો છો અને જે સંસાધન પહેલું ખતમ થાય છે. મોટાભાગની ક્ષમતાની ભૂલો પહેલી સંખ્યા પસંદ કરીને બીજી ક્યારેય ન માપવાથી થાય છે. બંને આ ક્રમમાં કરો, પછી હાર્ડવેરનો નિર્ણય અનુમાન રહેતો નથી.

ખાતાંની સંખ્યાને વ્યસ્ત કલાક સાથે સરખાવો

ખાતાંની સંખ્યા લાઇસન્સ અને સહાય મર્યાદા છે; વ્યસ્ત કલાક લોડ છે. તે કલાકમાં એકબીજા પર ચઢતાં કામોની યાદી બનાવો: કૉલ, દૂરસ્થ વ્યવસ્થાપન, મોટા ડાઉનલોડ, બેકઅપ અને ખાનગી એપ્લિકેશનોની વિનંતીઓ જે લોકોને રાહ જોવડાવે છે. પછી દરેક વસ્તુ માટે નોંધો કે તે ગેટવે ઓળંગે છે કે નહીં અને કઈ દિશામાં. કૉલ સમમિતીય અને વિલંબ પ્રત્યે સંવેદનશીલ છે, જ્યારે બેકઅપ એકદિશીય છે અને ધીમી શરૂઆત સહન કરે છે, તેથી તે માર્ગના જુદા જુદા ભાગો પર દબાણ લાવે છે.

દિશા નક્કી કરે છે કે કઈ લિંક મહત્વની છે. ઘરની અપલિંક ભાગ્યે જ સમમિતીય હોય છે, અને આખો દિવસ ડાઉનલોડ કરતી શાખા ગેટવે પરસેવો વળે તે પહેલાં ઘણા સમય પહેલાં તેની ડાઉનસ્ટ્રીમ મર્યાદા પર પહોંચે છે. દરેક વસ્તુની બાજુમાં દિશા અને ટનલનો વ્યાપ લખો, કારણ કે ફક્ત ખાનગી લક્ષ્યો વહન કરતું ગેટવે અને આખું ઇન્ટરનેટ ટ્રાફિક વહન કરતું ગેટવે બે જુદી માપન સમસ્યાઓ છે.

પૃષ્ઠભૂમિ લોડને તેની પોતાની હરોળ તરીકે ઉમેરો: ક્લાયન્ટ અપડેટ, ટેલિમેટ્રી અને ફોર્વર્ડિંગ સિવાય હોસ્ટ જે કંઈ કરે છે. આ બાઇટ ભૂલી જવા સહેલા છે અને તેમને એ જ ઇન્ટરફેસ ગણે છે.

લિંક પહેલાં ખતમ થતું સંસાધન શોધો

લિંક ફક્ત એક ઉમેદવાર છે. એક ટનલનું ક્રિપ્ટો કામ એક કોરને પકડી રાખી શકે છે જ્યારે ઇન્ટરફેસ અડધું ખાલી બેસે છે, અને ભરેલી કતાર એવા થ્રુપુટ પર કૉલ નકામા બનાવી શકે છે જે ગ્રાફ પર સામાન્ય લાગે છે. એક ધીમા માર્ગના અંતરે આવેલું લક્ષ્ય પણ ક્લાયન્ટની ખુરશીથી ગેટવેની નબળાઈ જેવું લાગી શકે છે. ત્રણ અવલોકનો આ કિસ્સાઓને અલગ પાડે છે, અને તેમાંથી કોઈને ફટાકડા-પરીક્ષણની જરૂર નથી.

ObservationWhat to inspect
one core busy, bytes steadyper-core CPU, implementation, offload status
calls degrade during transfersqueueing and the access link
one remote destination slowthat route and its service

જે ટ્રાન્સફર ચલાવવાની તમને પરવાનગી છે તેનાથી માપો, અને સમવર્તી કામ એકસાથે નહીં પણ પગલાંમાં ઉમેરો. ટકાઉ દર અને ઇન્ટરેક્ટિવ પ્રતિસાદ સાથે વાંચો, કારણ કે ફક્ત ટોચના દરની પરીક્ષા નકામી બનેલી સત્ર છુપાવે છે. જે ગેટવે કૉલ તૂટતા હોય ત્યારે તેનો મહત્તમ થ્રુપુટ પસાર કરે છે, તે પરીક્ષામાં પાસ થયું નથી.

પછી વૈકલ્પિક લોડ બંધ રાખીને ફરી ચલાવો. બેકઅપ બંધ થાય ત્યારે જે મર્યાદા ખસે છે તે ક્યારેય ગેટવેની મર્યાદા નહોતી.

તુલનાને એવી સંખ્યામાં ફેરવો જેનો તમે બચાવ કરી શકો

જે સંસાધન ખતમ થયું તે પસંદ કરો અને જરૂરિયાતને તેના એકમોમાં વ્યક્ત કરો: વ્યસ્ત કલાકમાં લક્ષ્ય ઉપયોગ પર કોર, દરેક દિશામાં બિટ પ્રતિ સેકન્ડ, અથવા વિલંબ મર્યાદા હેઠળ સમવર્તી સત્રો. અપડેટ, નિદાન અને પુનઃપ્રાપ્તિ માટે જગ્યા છોડો, કારણ કે માપેલી ટોચ પર બેઠેલા સર્વર પાસે તેને ચાલુ રાખતા કામ માટે કંઈ બચ્યું નથી. પછી સંખ્યાઓને તેમને ઉત્પન્ન કરનાર રૂપરેખાંકનની બાજુમાં લખો, ક્લાયન્ટ સંખ્યા અને વપરાયેલી પરીક્ષા સહિત.

કોર દીઠ વપરાશકર્તાનો આંકડો આ કસરતમાં સૌથી ઓછો સ્થાનાંતરિત થઈ શકે તેવો આંકડો છે, કારણ કે તે પ્રોટોકોલ મિશ્રણ અને ઉપકરણ પ્રોફાઇલ ધારે છે જે આગલી સાઇટ વહેંચતી નથી. માપ રાખો અને સૂત્ર છોડી દો. જ્યારે કોઈ વધુ પચાસ વપરાશકર્તાઓ માટે ક્ષમતા માંગે, ત્યારે પ્રામાણિક જવાબ તે પચાસના વ્યસ્ત-કલાકની પ્રોફાઇલ છે, ગુણાકાર નહીં.

થ્રુપુટની સાથે પ્રતિસાદ સમય પણ નોંધો. જે ક્ષમતા ફક્ત બલ્ક ટ્રાન્સફર જાળવે છે તે કૉલ પરના લોકો માટે ક્ષમતા નથી, અને આગલી સમીક્ષા આ ફરક વિશે પૂછશે.

ઉપર તરફ સ્કેલ કરવા અને ભૂમિકા વિભાજિત કરવા વચ્ચે પસંદ કરો

જ્યારે માપેલી મર્યાદા એક કોર હોય, ત્યારે સમાન ઝડપે વધુ કોર મદદ ન કરી શકે; ઝડપી કોર અથવા જુદું વર્કર મોડેલ મદદ કરી શકે. જ્યારે મર્યાદા કુલ CPU હોય, ત્યારે મોટું ઇન્સ્ટન્સ સીધો ઉપાય છે. જ્યારે મર્યાદા એક્સેસ લિંક હોય, ત્યારે કોઈ સર્વર ફેરફાર મદદ કરતું નથી અને તુલના પ્રદાતા પાસે પૂરી થાય છે. વેબ અને VPN ભૂમિકાઓને અલગ હોસ્ટ પર વિભાજિત કરવાથી બીજી વ્યવસ્થાપન સપાટીના ભોગે અલગતા મળે છે.

તે વિકલ્પોને એકબીજા સાથે નહીં, નોંધાયેલી સંખ્યા સાથે સરખાવો. જે ફેરફાર એવા સંસાધનને બમણું કરે જે મર્યાદા નહોતું, તે નફા વગરનો ખર્ચ છે, અને નોંધ જ તમને તે વિવાદ વગર કહેવા દે છે. ફેરફાર પછી એ જ લોડ સાથે ફરી માપો, નહીંતર તમે એક અનુમાનને બીજા સાથે બદલી નાખ્યું છે.

સંબંધિત લેખો