מוניטורינג לביצועי בקאנד¶
יש הבדל בין לדעת שהמערכת שלכם למעלה, לבין לדעת שהיא מהירה. ניטור זמינות כללי אומר לכם אם השרת עונה בכלל. מוניטורינג לביצועים הולך צעד עמוק יותר - הוא אומר לכם כמה זמן לוקח לכל בקשה, איפה בדיוק הזמן הזה מתבזבז, ואיזה חלק מהמשתמשים שלכם בכלל מרגיש בעיה.
למה ממוצע זמן תגובה מטעה¶
הטעות הנפוצה ביותר היא להסתכל על ממוצע זמן התגובה ולחשוב שהוא מספר כל הסיפור. הבעיה היא שממוצע יכול להסתיר בעיה אמיתית. תארו לעצמכם ש-95 אחוז מהבקשות חוזרות תוך 100 מילישניות, אבל 5 אחוז נתקעות ל-5 שניות בגלל שאילתה איטית מדי פעם. הממוצע ייראה סביר, אבל אלפי משתמשים חווים המתנה מייסרת בכל יום, ואף אחד לא רואה את זה בממוצע.
בדיוק בשביל זה משתמשים בפרסנטילים (percentiles) במקום, או בנוסף לממוצע. p50 (החציון) אומר מה זמן התגובה שחצי מהבקשות מהירות ממנו. p95 אומר מה זמן התגובה שרק 5 אחוז מהבקשות איטיות ממנו. p99 מראה את המקרים הקיצוניים ביותר. מסתכלים על p95 ו-p99 כי הם חושפים בדיוק את החוויה של המשתמשים שנתקלים בבעיה, שהממוצע פשוט טושטש.
מדדים מרכזיים מעבר לזמן תגובה¶
זמן תגובה הוא רק חלק מהתמונה. throughput מודד כמה בקשות המערכת מעבדת בשנייה, ועוזר להבין אם יש לכם מספיק קיבולת לעומס הנוכחי. אחוז השגיאות מראה כמה בקשות נכשלות, ועלייה פתאומית בו היא לרוב הסימן הראשון לבעיה לפני שהיא מורגשת בזמני תגובה. שימוש במשאבים - מעבד, זיכרון, חיבורים פתוחים למסד נתונים - עוזר לזהות צוואר בקבוק לפני שהוא הופך לתקלה מלאה.
אבחון מבוזר - כשבקשה אחת עוברת בכמה שירותים¶
במערכת מבוססת מיקרוסרביסים, בקשה אחת של משתמש יכולה לעבור דרך חמישה שירותים שונים לפני שהיא מקבלת תשובה. אם הבקשה איטית, איך יודעים איזה שירות אשם? כאן נכנס distributed tracing - כל בקשה מקבלת מזהה ייחודי (trace id) שעובר איתה בין כל השירותים, וכל שירות מתעד כמה זמן הוא לקח לטפל בחלק שלו. כלי אבחון כמו Jaeger או פתרונות מסחריים מציגים את זה כציר זמן ויזואלי, שמראה בדיוק איפה הזמן התבזבז לאורך כל השרשרת.
בלי tracing מבוזר, ניסיון לאתר בעיית ביצועים במערכת עם כמה שירותים דומה לחיפוש מחט בערימת שחת - עם tracing, רואים מיד איזה שירות ספציפי הוא הצוואר בקבוק.
הבעיה הקלאסית - שאילתת N+1¶
אחת הבעיות הנפוצות ביותר שמוניטורינג טוב חושף היא שאילתת N+1 - קוד שמריץ שאילתה אחת כדי לשלוף רשימה, ואז שאילתה נוספת בנפרד לכל פריט ברשימה כדי לשלוף מידע קשור. עם עשרה פריטים זה לא מורגש, אבל עם אלף פריטים זה פתאום אלף ואחת שאילתות במקום שתיים. כלי מוניטורינג שמראה כמות שאילתות למסד נתונים לכל בקשה חושף את הדפוס הזה מיד, כשמישהו רואה מספר שאילתות שגדל באופן ליניארי עם גודל הנתונים.
כלי APM - הסתכלות מקיפה על הביצועים¶
כלים בתחום שנקרא Application Performance Monitoring, כמו Datadog או New Relic, מאספים את כל המדדים האלה במקום אחד - זמני תגובה לפי endpoint, שאילתות איטיות למסד נתונים, שימוש במשאבים, ו-tracing מבוזר - ומציגים אותם בדשבורד אחד שמאפשר לצלול מהתמונה הכללית ישר לבקשה הבודדת שגרמה לבעיה.
איך מתחילים בפועל¶
אין צורך בכלים המתקדמים ביותר כדי להתחיל. אפילו מדידה בסיסית של p95 לכל endpoint, וספירת שאילתות מסד נתונים לכל בקשה, כבר חושפים את רוב הבעיות הנפוצות. השדרוג לכלי APM מלא מגיע בשלב מאוחר יותר, כשהמערכת גדלה מספיק שהתמונה נהיית מורכבת מכדי לעקוב אחריה ידנית.
איך לומדים לבנות מערכת שמנוטרת נכון¶
הבנת פרסנטילים ו-tracing היא תיאורטית קלה, אבל לדעת לזהות בעיית ביצועים אמיתית ולתקן אותה - זה נלמד רק על מערכת אמיתית עם עומס אמיתי. בקורס צד-שרת בונים מערכת ולומדים לאתר ולתקן בעיות ביצועים אמיתיות בתוכה.
מצאתם שה-API שלכם איטי ולא בטוחים איפה להתחיל לחפש? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.
לסיכום¶
מוניטורינג לביצועים אמיתי מסתכל הרבה מעבר לממוצע זמן תגובה - הוא בודק פרסנטילים כדי לחשוף את חווית המשתמשים האיטיים ביותר, עוקב אחרי בקשות בין שירותים עם tracing מבוזר, וחושף דפוסים בעייתיים כמו שאילתות N+1. ההשקעה הזו היא ההבדל בין לגלות בעיית ביצועים ממשתמש מתלונן, לבין לתפוס אותה בדשבורד לפני שמישהו בכלל שם לב.