מבצע מעקב

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

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

זיהוי מדדי זמן אחזור

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

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

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

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

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

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

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

לא רק הממוצע

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

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

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

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

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

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

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

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

מעקב בענן

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

במדריך הרישום ביומן יש דוגמה למיירט מותאם אישית של רישום ביומן ב-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. כדי ליצור מדדים באמצעות היומנים שנשלחים ל-Google 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, פועלים לפי המדריך להגדרת התראות על מדדים מבוססי-יומנים.