פתרון עקיבה שמסבירה התנהגות

פתרון התרגיל הראשון

בגרסת ההמתנה קטע WaitStart עד WorkStop כולל זמן שבו הthread אינו רץ. בגרסת החישוב נצפה ליותר צריכת CPU באותו תחום, אבל המספרים בפועל תלויים בworkload, באופטימיזציה ובתזמון. לכן התשובה היא trace עם תחומים מסומנים והסבר, ולא מספר זמן קבוע מראש.

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

פתרון התרגיל השני

אובייקט העבודה יחזיק activity ID, attempt ID וtimestamp של enqueue. הworker יפיק dequeue עם אותם מזהים ואז ימשיך את האירועים הרגילים. אם עבודה נוצרת כתוצאה מעבודה אחרת, ניתן לה ליצור activity חדש ולשמור קשר לאב.

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

פתרון התרגיל השלישי

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

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