9.10 - בדיקת שרת תחת עומס וכשלי רשת - פתרון

פתרון מדידה שאפשר לפרש

פתרון ראשון - דירוג ומכנה

הבדיקות הבאות מתווספות לאותו קובץ שבו מוגדרת פונקציית האחוזון.

assert_eq!(percentile(&[], 99), None);
assert_eq!(percentile(&[10], 99), Some(10));
assert_eq!(percentile(&[10, 20, 30, 40], 50), Some(20));
assert_eq!(percentile(&[10, 20, 30, 40], 99), Some(40));

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

פתרון שני - משתנה אחד בכל השוואה

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

sudo ip netns exec amit-server tc qdisc replace dev amit-s root netem delay 20ms
sudo ip netns exec amit-client ./load 192.0.2.1:43000
sudo ip netns exec amit-server tc qdisc replace dev amit-s root netem loss 1%
sudo ip netns exec amit-client ./load 192.0.2.1:43000
sudo ip netns exec amit-server tc qdisc replace dev amit-s root netem delay 20ms loss 1%
sudo ip netns exec amit-client ./load 192.0.2.1:43000

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

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

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

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

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