מבצע מעקב

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

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

זיהוי מדדי השהיה

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

המדדים המומלצים למעקב כוללים:

• משך הבקשה
• משך הבקשה ברמת הפירוט של תת-המערכת (כמו קריאות ל-API)
• משך המשימה

זיהוי מדדי תפוקה

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

ריכזנו כאן כמה מדדים מומלצים למעקב:

• שאילתות לשנייה (QPS)
• גודל הנתונים שמועברים בשנייה
• מספר פעולות הקלט/פלט לשנייה
• ניצול משאבים, כמו שימוש במעבד (CPU) או בזיכרון
• גודל ה-backlog של העיבוד, למשל pub/sub או מספר השרשורים

לא רק הממוצע

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

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

מעקב בצד השרת לקבלת תוצאות מפורטות

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

מעקב בדפדפן כדי לקבל תמונה מלאה

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

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

• זמני טעינת דף
• זמני טעינה של הפניות אוטומטיות
• זמני התגובה של השרת

מעקב בענן

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

במדריך בנושא רישום ביומן יש דוגמה של interceptor מותאם אישית לרישום ביומן של gRPC שנכתב עבור ספריית הלקוח של Python. בדוגמה הזו, ה-interceptor קורא ל-logger.log_struct() כדי לשלוח מילון Python של נתוני יומן מובנים ל-Cloud Logging, שמאחסן אותם בשדה jsonPayload של רשומת היומן:

logger.log_struct({
    "method": method_name,
    "elapsed_ms": elapsed_milliseconds,
    "is_fault": is_fault,
})

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

לחלופין, אתם יכולים להשתמש בספריות הלקוח של Cloud Monitoring כדי להגדיר מדדים בקוד ולשלוח אותם ישירות ל-Monitoring, בנפרד מהיומנים.

דוגמה למדדים מבוססי-יומן

נניח שאתם רוצים לעקוב אחרי הערך של is_fault כדי להבין טוב יותר את שיעורי השגיאות באפליקציה. מכיוון ש-logger.log_struct() כותב שדות מילון מובְנים בקטע jsonPayload בכל רשומה ב-Cloud Logging, אפשר ליצור מדד מונה בשם ErrorCount עם מסנן שתואם לבקשות שנכשלו, כמו jsonPayload.is_fault = true.

ב-Cloud Logging, תוויות מאפשרות לקבץ את המדדים לקטגוריות על סמך נתונים אחרים ביומנים. אפשר להגדיר תווית STRING בשם Method בשדה jsonPayload.method שנשלח ל-Cloud Logging כדי לפצל את מספר השגיאות לפי השיטה של Google Ads API.

אחרי שמגדירים את המדד ErrorCount ואת התווית Method, אפשר ליצור תרשים חדש ב-Cloud Monitoring כדי לעקוב אחרי ErrorCount, מקובץ לפי Method.

התראות

ב-Cloud Monitoring ובכלים אחרים אפשר להגדיר מדיניות התראות, שקובעת מתי ואיך המדדים יפעילו התראות. כדי להגדיר התראות ב-Cloud Monitoring, פועלים לפי המדריך להתראות על מדדים מבוססי-יומנים.