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