לקרוא את זמני ה-proxy של cURL מצד הלקוח

פרשו זמני חיבור, TLS, בייט ראשון וסך הכול בלי לייחס עבודה במעלה הזרם שלא נצפתה למדידה של ה-proxy בלבד.

נניח ש-cURL פותח חיבור TCP חדש אל proxy HTTP פשוט, מקים מנהרת HTTPS ומוריד תגובה אחת. הזמנים מתארים אבני דרך ש-cURL צפה בהן בדרך הזו.

ערךאבן דרך הנמדדת מתחילת ההעברה
time_connectהחיבור אל ה-proxy הושלם
time_appconnectלחיצת היד של TLS הרלוונטית הושלמה
time_starttransferהתקבל הבייט הראשון של התגובה
time_totalההעברה הסתיימה

לקליטה להמחשה ב-POSIX shell:

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 ציבורית מותרת בלי פרטי גישה ל-proxy, אפשר להחליף את ה-proxy שבדוגמה ברשומה של HTTP מתוך רשימת ה-proxy מסוג HTTP. הערכים הם שניות מצטברות. אלה אינם ארבעה משכים עצמאיים שיש לחבר. שמרו את שגיאת ההעברה ואת מצב התגובה לצד המספרים: חיבור שנכשל או מנהרה שנדחתה לא הגיעו לכל אבן דרך מאוחרת.

מה החיסור יכול לומר לכם

עבור תגובה אחת מוצלחת, time_total פחות time_starttransfer מתאר את המרווח שנותר לאחר הגעת הבייט הראשון. מדובר בעיקר בהעברת התגובה המאוחרת ובעבודה הנלווית בצד הלקוח. זה אינו הזמן שלקח ל-proxy להתחבר לאתר, משום שזה קרה לפני שהתגובה יכלה להגיע.

באותו אופן, time_starttransfer פחות time_connect עשוי לכלול הקמת מנהרה, TLS, המתנות של הרשת שמעלה הזרם, עבודת השרת ועיבוד נוסף. לקרוא לכל ההפרש "השהיית proxy" פירושו לייחס כמה מרכיבים למשתתף אחד.

כדי להפריד את המתנות ה-proxy ב-DNS, בחיבור ובתגובה, השיגו תצפיות או עקבות מתאימות מצד ה-proxy. הלקוח אינו מקבל את חותמות הזמן הפנימיות הללו רק משום שהוא משתמש ב-HTTP CONNECT.

השוו העברות שקולות. הפניות מפנות מוסיפות זמנים של כמה בקשות, ואילו שימוש חוזר בחיבורים וריבוב משנים איזו עבודת הכנה נדרשת. תעדו את התנאים האלה לפני שאתם משווים את המספרים של proxy אחד לאלה של אחר.

מאמרים קשורים