તમારો ડાઉનલોડ ઝડપી છે, તો પછી દરેક ક્લિક ધીમું કેમ લાગે છે?

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

ઝડપી ફાઇલ, ધીમું ક્લિક: બે અલગ આંકડા

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

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

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

ફરિયાદ માપો, જોડાણ નહીં

વપરાશકર્તાએ કહેલા વાક્ય સાથે મેળ ખાતું માપ પસંદ કરો. ધીમા ડાઉનલોડને યોગ્ય દિશામાં ટકાઉ દરની જરૂર છે; મોડી પડતી કૉલને તે એપ્લિકેશનનાં પોતાનાં આંકડાઓની જરૂર છે; ધીમે શરૂ થતા પૃષ્ઠને નામ ઉકેલ અને સ્થાપનના સમયની જરૂર છે.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

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

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

ICMPને જવાબ નહીં, સૂચન તરીકે લો. પ્રતિસાદ આપતું હોસ્ટ તમારી એપ્લિકેશન જે માર્ગ વાપરે છે તેના કરતાં અલગ માર્ગ પર ઇકો વિનંતીઓ સંભાળી શકે છે, અને એક ખોવાયેલો જવાબ એ પુરાવો નથી કે દરેક એપ્લિકેશન પેકેટ ગુમાવી રહી છે.

ભાર હેઠળનો વિલંબ કતારની સમસ્યા છે

લોકોને સૌથી વધુ મૂંઝવતી પેટર્ન એ છે કે જોડાણ નિષ્ક્રિય હોય ત્યારે સારું લાગે અને બેકઅપ દરમિયાન નકામું બની જાય. એ કતાર છે, ક્ષમતા નહીં. ભરાયેલી અપલિંક દરેક બીજા પેકેટની સામે બફર બનાવે છે, તેથી કીબોર્ડનું દબાણ અપલોડના એક ભાગ પાછળ રાહ જુએ છે.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

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

વૈકલ્પિક પૃષ્ઠભૂમિ ટ્રાફિક ઘટાડવો ઘણી વાર એગ્રેસ દેશ બદલવા કરતાં વધુ મદદ કરે છે. તે સસ્તું, ઉલટાવી શકાય તેવું અને એક મિનિટમાં ચકાસી શકાય તેવું પણ છે. જો કતાર સંભાળી ન શકાય તો મોટા અપલોડ કામકાજના સમય બહાર ગોઠવો, અને જો દિવસ દરમિયાન ચલાવવા પડે તો તેમનો દર મર્યાદિત કરો. રાઉટર ટેકો આપે ત્યારે કતાર સંચાલનની સેટિંગ વધુ સારો ઉપાય છે.

એક વસ્તુ બદલો અને સમાનને સમાન સાથે સરખાવો

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

તમે શું માપ્યું, કયા ગંતવ્ય સામે, કઈ વખતે અને કઈ સેટિંગ સાથે—લખો. તે ચાર હકીકતો વિના સરખામણી પુનરાવર્તિત કરી શકાતી નથી, અને આગળની વ્યક્તિ શૂન્યથી શરૂ કરશે.

પછી ટિકિટમાંના દાવા સાથે સાધનને મેળવો. "ઇન્ટરનેટ ધીમું" માપ નથી; "આ હોસ્ટ સુધી પ્રથમ બાઇટને 900 ms લાગ્યા જ્યારે થ્રુપુટ સારું હતું" એ માપ છે, અને તે સીધું ક્ષમતા તરફ નહીં, વિલંબ તરફ ઇશારો કરે છે.