אופטימיזציה של הביצועים מתחילה בזיהוי מדדי מפתח, בדרך כלל כאלה שקשורים לזמן האחזור ולתפוקה. הוספת מעקב כדי לתעד ולעקוב אחרי המדדים האלה חושפת נקודות חולשה באפליקציה. באמצעות מדדים, אפשר לבצע אופטימיזציה כדי לשפר את מדדי הביצועים.
בנוסף, הרבה כלי מעקב מאפשרים להגדיר התראות לגבי המדדים, כדי לקבל עדכון כשמגיעים לסף מסוים. לדוגמה, אתם יכולים להגדיר התראה שתשלח לכם אם אחוז הבקשות שנכשלו יעלה ביותר מ-x% מהרמות הרגילות. כלי מעקב יכולים לעזור לכם לזהות מהם הביצועים הרגילים ולזהות עליות חריגות בחביון, בכמויות השגיאות ובמדדים מרכזיים אחרים. היכולת לעקוב אחרי המדדים האלה חשובה במיוחד במהלך תקופות קריטיות לעסק, או אחרי שמעבירים קוד חדש לסביבת הייצור.
זיהוי מדדי זמן אחזור
חשוב לוודא שממשק המשתמש מגיב בצורה הטובה ביותר שאפשר, ולזכור שהמשתמשים מצפים לסטנדרטים גבוהים יותר מאפליקציות לנייד. כדאי גם למדוד את זמן האחזור ולעקוב אחריו בשירותי קצה עורפי, במיוחד כי הוא עלול לגרום לבעיות ברוחב הפספוס אם לא בודקים אותו.
המדדים המומלצים למעקב כוללים:
- משך הבקשה
- משך הבקשה ברמת פירוט של מערכת משנה (כמו קריאות ל-API)
- משך העבודה
זיהוי מדדי תפוקה
קצב העברת הנתונים הוא מדד של המספר הכולל של בקשות שטופלו במהלך תקופה מסוימת. התפוקה יכולה להיות מושפעת מזמן האחזור של מערכות משנה, ולכן יכול להיות שתצטרכו לבצע אופטימיזציה של זמן האחזור כדי לשפר את התפוקה.
ריכזנו כאן כמה מדדים מומלצים למעקב:
- שאילתות לשנייה (QPS)
- גודל הנתונים שמועברים בכל שנייה
- מספר פעולות הקלט/פלט לשנייה
- ניצול משאבים, כמו שימוש במעבד (CPU) או בזיכרון
- גודל ה-backlog של העיבוד, כמו pub/sub או מספר השרשורים
לא רק הממוצע
טעות נפוצה במדידת הביצועים היא התמקדות רק בממוצע. הנתון הזה שימושי, אבל הוא לא מספק תובנות לגבי התפלגות זמן האחזור. מדד טוב יותר למעקב הוא האחוזונים של הביצועים, למשל האחוזון ה-50, ה-75, ה-90 או ה-99 של מדד מסוים.
בדרך כלל, אפשר לבצע אופטימיזציה בשני שלבים. קודם כל, מבצעים אופטימיזציה לזמן האחזור באחוזון ה-90. לאחר מכן, כדאי להתייחס לאחוזון ה-99 – שנקרא גם חביון זנב: החלק הקטן של הבקשות שלוקח הרבה יותר זמן להשלים.
מעקב בצד השרת לקבלת תוצאות מפורטות
בדרך כלל עדיף להשתמש בפרופילים בצד השרת למעקב אחרי מדדים. בדרך כלל קל יותר להגדיר את הצד של השרת, יש גישה לנתונים מפורטים יותר והוא פחות מושפע מבעיות בקישוריות.
מעקב בדפדפן כדי לקבל תמונה מלאה
יצירת פרופיל של הדפדפן יכולה לספק תובנות נוספות לגבי חוויית משתמשי הקצה. הוא יכול להראות אילו דפים כוללים בקשות איטיות, ואז תוכלו להשוות אותם לנתונים ממעקב בצד השרת כדי לבצע ניתוח נוסף.
ב-Google Analytics יש מעקב מוכן מראש אחר זמני טעינת הדפים בדוח על זמני טעינת הדפים. הדוח הזה מספק כמה תצוגות שימושיות להבנת חוויית המשתמש באתר, במיוחד:
- זמני טעינת הדפים
- זמני טעינה של הפניות אוטומטיות
- זמני תגובה של השרת
מעקב בענן
יש הרבה כלים שבהם אפשר להשתמש כדי לתעד ולעקוב אחרי מדדי הביצועים של האפליקציה. לדוגמה, אתם יכולים להשתמש ב-Google Cloud Logging כדי לרשום ביומן מדדי ביצועים בפרויקט Google Cloud, ואז להגדיר לוחות בקרה ב-Google Cloud Monitoring כדי לעקוב אחרי המדדים שרשומים ביומן ולפלח אותם.
במדריך בנושא רישום ביומן יש דוגמה לרישום ביומן ב-Google 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 מופיעות במדריך ההתראות.