למה רוב בעיות הביצועים הן בעיות תזמון

כשמערכת איטית, האינטואיציה הראשונה היא לחשוב שיש יותר מדי עבודה. יותר חישוב, יותר בקשות, יותר עומס ממה שהמערכת יכולה להכיל.

אבל ברוב המקרים - זו אבחנה שגויה.

הבעיה האמיתית היא לא כמה עבודה יש, אלא מתי היא מתבצעת.

יש כוח חישוב, ובכל זאת דברים נתקעים

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

ובכל זאת, דברים נתקעים.

לא כי אין משאבים, אלא כי העבודה מגיעה בזמן הלא נכון, או מסודרת בצורה הלא נכונה.

Head-of-line blocking

כאן נכנס עולם ה-queueing.

כשעבודות מגיעות מהר יותר ממה שאפשר לעבד באותו רגע - הן נכנסות לתור.

התור עצמו הוא לא בעיה. הבעיה מתחילה כשאין הבחנה בין סוגי עבודות.

זה מוביל ל-head-of-line blocking.

עבודה קצרה ופשוטה נתקעת מאחורי עבודה ארוכה וכבדה.

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

מבחינת המשתמש: “למה פעולה פשוטה לוקחת כל כך הרבה זמן?”

מבחינת המערכת: “פשוט חיכיתי”.

המתנה, לא חישוב איטי

זו בדיוק הנקודה שבה ביצועים נראים גרועים, גם אם סך העבודה קטן יחסית.

כי משתמשים לא חווים ממוצעים. הם חווים המתנה.

והמתנה נוצרת מתזמון גרוע, לא מחישוב איטי.

בעולמות Inference זה בולט במיוחד

Inference כולל:

• בקשות בגדלים שונים
• מודלים שונים
• זמני חישוב שונים

כשכולן נכנסות לאותו תור, בלי תזמון חכם:

• בקשה קטנה נמחצת
• latency קופץ
• והמערכת נראית לא יציבה

לא כי המאיץ איטי - אלא כי הוא עסוק בדבר הלא נכון בזמן הלא נכון.

Scheduling הוא בעיה ארכיטקטונית, לא תפעולית

כאן מתברר ש-scheduling הוא בעיה מרכזית, לא שולית.

איך מחליטים:

• איזו עבודה תרוץ עכשיו
• איזו תחכה
• ואיך למנוע מעבודה אחת לחסום אחרות

זו החלטה ארכיטקטונית, לא רק תפעולית.

המשל

קופה אחת בסופר. לקוח עם עגלה מלאה עומד ראשון. מאחוריו - חמישה לקוחות עם פריט אחד.

אין מחסור בקופאיות. יש בעיית סדר.

סיכום

רוב בעיות הביצועים לא נפתרות על ידי הוספת כוח חישוב.

הן נפתרות כששואלים:

• איך העבודה מסודרת
• מתי כל דבר רץ
• ואיפה המתנה מיותרת נוצרת

כי ביצועים הם לא רק עניין של כמות עבודה - אלא של תזמון.