אופטימיזציה של הביצועים מתחילה בזיהוי מדדי מפתח, בדרך כלל כאלה שקשורים לזמן האחזור ולתפוקה. הוספת מעקב כדי לתעד ולעקוב אחרי המדדים האלה חושפת נקודות חולשה באפליקציה. בעזרת מדדים, אפשר לבצע אופטימיזציה כדי לשפר את מדדי הביצועים.
בנוסף, הרבה כלי מעקב מאפשרים להגדיר התראות למדדים, כדי לקבל עדכון כשמגיעים לסף מסוים. לדוגמה, אתם יכולים להגדיר התראה שתשלח לכם הודעה כשאחוז הבקשות שנכשלו עולה ביותר מ-x% מהרמות הרגילות. כלים למעקב יכולים לעזור לכם לזהות מהם הביצועים הרגילים ולזהות עליות חריגות בחביון, בכמויות השגיאות ובמדדים מרכזיים אחרים. היכולת לעקוב אחרי המדדים האלה חשובה במיוחד במהלך תקופות קריטיות לעסק, או אחרי שקוד חדש הועבר לסביבת הייצור.
זיהוי מדדי השהיה
חשוב לוודא שממשק המשתמש מגיב מהר ככל האפשר, ולזכור שהמשתמשים מצפים לסטנדרטים גבוהים יותר מאפליקציות לנייד. חשוב גם למדוד את זמן האחזור ולעקוב אחריו בשירותי קצה עורפי, במיוחד כי הוא עלול לגרום לבעיות ברוחב הפסקה אם לא בודקים אותו.
המדדים המומלצים למעקב כוללים:
- משך הבקשה
- משך הבקשה ברמת פירוט של מערכת משנה (כמו קריאות ל-API)
- משך העבודה
זיהוי מדדי תפוקה
קצב העברת הנתונים הוא מדד של המספר הכולל של בקשות שטופלו במהלך תקופה מסוימת. זמן האחזור של מערכות משנה יכול להשפיע על קצב העברת הנתונים, ולכן יכול להיות שתצטרכו לבצע אופטימיזציה של זמן האחזור כדי לשפר את קצב העברת הנתונים.
ריכזנו כאן כמה מדדים מומלצים למעקב:
- שאילתות לשנייה (QPS)
- גודל הנתונים שהועברו בשנייה
- מספר פעולות הקלט/פלט לשנייה
- ניצול משאבים, כמו שימוש במעבד (CPU) או בזיכרון
- גודל ה-backlog של העיבוד, כמו pub/sub או מספר השרשורים
לא רק הממוצע
טעות נפוצה במדידת הביצועים היא התמקדות רק בממוצע. הנתון הזה שימושי, אבל הוא לא מספק תובנות לגבי התפלגות זמן האחזור. מדד טוב יותר למעקב הוא האחוזונים של הביצועים, למשל האחוזון ה-50, ה-75, ה-90 או ה-99 של מדד מסוים.
בדרך כלל, אפשר לבצע אופטימיזציה בשני שלבים. קודם כל, מבצעים אופטימיזציה לזמן האחזור באחוזון ה-90. לאחר מכן, כדאי להתייחס לאחוזון ה-99 – שנקרא גם חביון זנב: החלק הקטן של הבקשות שנדרש להן הרבה יותר זמן להשלמה.
מעקב בצד השרת לתוצאות מפורטות
בדרך כלל עדיף להשתמש בפרופילים בצד השרת כדי לעקוב אחרי מדדים. בדרך כלל קל יותר להטמיע את הצד של השרת, הוא מאפשר גישה לנתונים מפורטים יותר ופחות מושפע מבעיות בקישוריות.
מעקב בדפדפן כדי לקבל תצוגה מקצה לקצה
יצירת פרופיל של הדפדפן יכולה לספק תובנות נוספות לגבי חוויית משתמשי הקצה. הוא יכול להראות אילו דפים כוללים בקשות איטיות, ואז תוכלו להשוות את הנתונים לנתוני המעקב בצד השרת כדי לבצע ניתוח נוסף.
ב-Google Analytics יש מעקב מוכן מראש אחר זמני טעינת הדפים בדוח על זמני טעינת הדפים. הדוח הזה מספק כמה תצוגות שימושיות להבנת חוויית המשתמש באתר, ובמיוחד:
- זמני טעינת הדפים
- זמני טעינה של הפניות אוטומטיות
- זמני תגובה של השרת
מעקב בענן
יש הרבה כלים שבהם אפשר להשתמש כדי לתעד ולעקוב אחרי מדדי הביצועים של האפליקציה. לדוגמה, אתם יכולים להשתמש ב-Google Cloud Logging כדי לרשום ביומן מדדי ביצועים בפרויקט Google Cloud, ואז להגדיר לוחות בקרה ב-Google Cloud Monitoring כדי לעקוב אחרי המדדים שרשומים ביומן ולפלח אותם.
במדריך בנושא רישום ביומן יש דוגמה לרישום ביומן ב-Cloud Logging מתוך interceptor מותאם אישית בספריית הלקוח של Python. אחרי שהנתונים האלה יהיו זמינים ב-Google Cloud, תוכלו ליצור מדדים על סמך הנתונים שרשומים ביומן כדי לקבל תובנות לגבי האפליקציה באמצעות Google Cloud Monitoring. כדי ליצור מדדים באמצעות היומנים שנשלחים אל Cloud Logging, אפשר להיעזר במדריך בנושא מדדים מבוססי-יומן שמוגדרים על ידי המשתמש.
לחלופין, אפשר להשתמש בספריות הלקוח של Monitoring כדי להגדיר מדדים בקוד ולשלוח אותם ישירות ל-Monitoring, בנפרד מהיומנים.
דוגמה למדדים מבוססי-יומנים
נניח שאתם רוצים לעקוב אחרי הערך is_fault כדי להבין טוב יותר את שיעורי השגיאות באפליקציה. אפשר לחלץ את הערך is_fault מהיומנים למדד חדש של מונה, ErrorCount.
ב-Cloud Logging, תוויות מאפשרות לקבץ את המדדים לקטגוריות על סמך נתונים אחרים ביומנים. אתם יכולים להגדיר תווית לשדה method שנשלח אל Cloud Logging כדי לראות את פירוט מספר השגיאות לפי שיטת Google Ads API.
אחרי שמגדירים את המדד ErrorCount ואת התווית Method, אפשר ליצור תרשים חדש בלוח בקרה של Monitoring כדי לעקוב אחרי ErrorCount, מקובץ לפי Method.
התראות
ב-Cloud Monitoring ובכלים אחרים אפשר להגדיר מדיניות התראות שמציינת מתי ואיך המדדים שלכם צריכים להפעיל התראות. הוראות להגדרת התראות ב-Cloud Monitoring מופיעות במדריך ההתראות.