ક્લાયન્ટ બાજુથી cURL પ્રોક્સી સમય વાંચો

જોડાણ, TLS, પ્રથમ બાઇટ અને કુલ સમયનું અર્થઘટન કરો, જોયા વિનાના ઉપરના કામને ફક્ત પ્રોક્સી માપણીને આભારી ન ગણતા.

ધારો કે cURL સાદા HTTP પ્રોક્સી સાથે નવું TCP જોડાણ ખોલે છે, HTTPS સુરંગ સ્થાપે છે અને એક પ્રતિસાદ ડાઉનલોડ કરે છે. આ સમય તે પથ પર cURL એ જોયેલા માઇલસ્તંભોનું વર્ણન કરે છે.

મૂલ્યસ્થાનાંતરણની શરૂઆતથી માપેલો માઇલસ્તંભ
time_connectપ્રોક્સી સાથેનું જોડાણ પૂર્ણ થયું
time_appconnectસંબંધિત TLS હેન્ડશેક પૂર્ણ થયો
time_starttransferપ્રતિસાદનો પ્રથમ બાઇટ મળ્યો
time_totalસ્થાનાંતરણ પૂરું થયું

ઉદાહરણરૂપ POSIX-શેલ કેપ્ચર માટે:

curl --proxy http://proxy.example:8080 \
  --output /dev/null \
  --write-out 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

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

બાદબાકી શું કહી શકે

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

એ જ રીતે time_starttransfer માંથી time_connect બાદ કરતાં સુરંગ નિર્માણ, TLS, ઉપરના નેટવર્કની રાહ, સર્વરનું કામ અને અન્ય પ્રક્રિયા સમાવી શકાય. આખા તફાવતને "પ્રોક્સી લેટન્સી" કહેવું એ ઘણા ઘટકોને એક ભાગીદાર પર મૂકવા જેવું છે.

પ્રોક્સીની ઉપરની DNS, જોડાણ અને પ્રતિસાદની રાહ અલગ કરવા પ્રોક્સીની બાજુથી સંબંધિત નિરીક્ષણો કે ટ્રેસ મેળવો. ક્લાયન્ટને ફક્ત HTTP CONNECT વાપરવાથી તે આંતરિક સમયચિહ્નો મળતા નથી.

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

સંબંધિત લેખો