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

કયો આંકડો તમારા પ્રશ્નનો જવાબ આપે છે?

કામઉપયોગી અવલોકન
નાનું પાનું ખોલવું અથવા ટૂંકી API વિનંતી મોકલવીકનેક્શન સ્થાપવા સહિત પ્રતિસાદ મળવા સુધીનો સમય.
ફાઇલ ડાઉનલોડ કરવીયોગ્ય પરીક્ષણ ફાઇલથી કુલ ટ્રાન્સફર થયેલા બાઇટ અને સરેરાશ થ્રૂપુટ.
ઘણી વિનંતીઓમાં એપનો પ્રતિસાદ ઝડપી રાખવોઅપેક્ષિત કાર્યભાર હેઠળ સામાન્ય પ્રતિસાદ સમય, નિષ્ફળતાઓ અને કનેક્શનનો પુનઃઉપયોગ.

ICMP ping અલગ પરીક્ષણ છે. પ્રોક્સી સેવા ઉપલબ્ધ ન હોય તોય સર્વર ping નો જવાબ આપી શકે, અથવા પ્રોક્સી કામ કરતો હોય ત્યારે ping રોકી શકે. પ્રોક્સીના સરનામા સુધી આવવા-જવાનો સમય પ્રોક્સીથી તમારા લક્ષ્ય સુધીનું કનેક્શન પણ ગણતો નથી.

ખરેખરનું ટ્રાન્સફર માપો

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

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin

ઉદાહરણનો પ્રોક્સી અને ફાઇલ URL બંને બદલો. 404 પાનું કે ઍક્સેસ નકારતો પ્રતિસાદ ઝડપથી મળે તોય તે ડાઉનલોડનો માન્ય માપદંડ નથી. ઝડપ સરખાવતાં પહેલાં સ્થિતિ, અપેક્ષિત ફાઇલ કદ અને સામગ્રી તપાસો.

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

સરખામણીની શરતો સમાન રાખો

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

કૅશમાંની ફાઇલ અને નવું ડાઉનલોડ સેવાની અંદર અલગ માર્ગે જઈ શકે. નવું કનેક્શન સ્થાપ્યા પછીની વિનંતી અને હાલનું કનેક્શન ફરી વાપરતી વિનંતી પણ એવી હોઈ શકે. એપને કયું વર્તન જોઈએ તે નક્કી કરીને સતત એ જ માપો.

કાર્યભાર મુજબ પસંદ કરો

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

ProxyHub પ્રોક્સી યાદી દરેક IP માટે સ્વતંત્ર થ્રૂપુટ માપ આપતી નથી. પ્રોટોકોલ કે દેશનું ફિલ્ટર ઝડપનો ક્રમ નથી.

સંબંધિત લેખો