Latency, Bandwidth ו-Throughput - ולמה כולם מתבלבלים ביניהם

אחרי שהבנו מה זה Packet, מה זה Connection, ואיך פרוטוקולים מתנהגים, אפשר סוף-סוף לשאול את השאלה שמטרידה כמעט כל מערכת: למה זה איטי?

התשובה מתחילה בהבחנה בין שלושה מושגים שנשמעים דומים - אבל מתארים בעיות שונות לגמרי.

Latency: כמה זמן לוקח להתחיל לקבל תשובה

Latency הוא זמן ההמתנה. הרגע שבין “שלחתי” ל-”התחיל להגיע משהו”.

זהו מדד של תגובתיות, לא של קצב.

Latency מושפע מ:

• מרחק לוגי ברשת
• מספר שכבות ומתווכים
• תיאום בין צדדים
• ותורים שנוצרים בדרך

גם אם נשלח רק Packet קטן - Latency עדיין קיים.

Bandwidth: כמה אפשר להעביר במקביל

Bandwidth מתאר קיבולת. כמה מידע אפשר להעביר בפרק זמן נתון.

זהו פוטנציאל, לא הבטחה.

רוחב פס גבוה אומר: אם הכול זורם - אפשר להזרים הרבה.

אבל הוא לא אומר:

• מתי המידע יתחיל להגיע
• או אם הוא יגיע בזמן

Throughput: מה באמת עבר בפועל

Throughput הוא התוצאה בפועל. כמה מידע עבר בהצלחה לאורך זמן.

הוא מושפע מ:

• Bandwidth
• Latency
• אובדן Packets
• תורים
• ופרוטוקול שנבחר

Throughput הוא מה שמרגישים - לא מה שמובטח.

למה קל כל כך להתבלבל

מערכת יכולה להיות:

• עם Bandwidth גבוה
• Throughput סביר
• ועדיין להרגיש איטית

למה? כי Latency גבוה גורם לכל פעולה להרגיש “תקועה”, גם אם בסך הכול עובר הרבה מידע.

זו הסיבה שמערכות רבות נראות חזקות על הנייר - ומאכזבות במציאות.

המשל

אפשר לחשוב על כביש מהיר.

Latency הוא הזמן שלוקח להגיע לכניסה לכביש. Bandwidth הוא מספר הנתיבים. Throughput הוא מספר המכוניות שעברו בפועל.

כביש עם עשרה נתיבים לא עוזר, אם הפקק הוא ביציאה מהעיר.

ההשלכה המערכתית

אופטימיזציה בלי להבין את ההבדל בין שלושת המושגים כמעט תמיד מטפלת בבעיה הלא נכונה.

לפעמים צריך:

לקצר Latency ולא להגדיל Bandwidth.

לפעמים צריך:

לשפר Throughput ולא לגעת בזמן תגובה.

בלי ההבחנה הזו - כל שיפור הוא ניחוש.

מבט קדימה

ברגע שמבינים ש-Latency אינו נעלם מעצמו, מתגלה הגורם השקט שמעצים אותו: תורים.

בפוסט הבא נעמיק ב-Queues - ולמה הם נוצרים גם כשנדמה שיש מספיק משאבים.