כשמשווים את הביצועים, חשוב להגדיר מראש מה אתם רוצים ללמוד מהבדיקה. לדוגמה:
- מה התפוקה המקסימלית שהמערכת יכולה להשיג?
- כמה זמן נמשכת שאילתה או עומס עבודה מסוימים?
- איך הביצועים משתנים ככל שכמות הנתונים גדלה?
- איך משווים בין הביצועים של שתי מערכות שונות?
- בכמה זמן מנוע העמודות מקצר את זמן התגובה של ביצועי השאילתה?
- מה העומס שמסד נתונים יכול לעמוד בו לפני שצריך לשקול שדרוג למכונה חזקה יותר?
הבנת היעדים של מחקר הביצועים עוזרת להבין איזו השוואה צריך להריץ, איזו סביבה נדרשת ואילו מדדים צריך לאסוף.
יכולת חזרה
כדי להסיק מסקנות מבדיקות ביצועים, התוצאות של הבדיקה צריכות להיות ניתנות לשחזור. אם יש שונות רבה בתוצאות הבדיקה, יהיה קשה להעריך את ההשפעה של השינויים שביצעתם באפליקציה או בהגדרות המערכת. כדי להקטין את מידת השונות, מומלץ להריץ את הבדיקות כמה פעמים או למשך תקופות ארוכות יותר כדי לקבל יותר נתונים.
מומלץ להריץ בדיקות ביצועים במערכות שמבודדות ממערכות אחרות. הפעלה בסביבה שבה מערכות חיצוניות יכולות להשפיע על הביצועים של האפליקציה עלולה להוביל למסקנות שגויות. בדרך כלל אי אפשר להשיג בידוד מלא כשמריצים בסביבת ענן עם ריבוי דיירים, ולכן צפויים הבדלים גדולים יותר בתוצאות
כדי להבטיח את היכולת לשחזר את התוצאות, צריך לוודא שעומס העבודה של הבדיקה נשאר זהה בין ההרצות. מותר להשתמש בערכים אקראיים מסוימים כקלט לבדיקה, כל עוד האקראיות לא גורמת להתנהגות שונה באופן משמעותי של האפליקציה. אם קלט לקוח שנוצר באופן אקראי משנה את השילוב של פעולות קריאה וכתיבה מהרצה להרצה, הביצועים ישתנו באופן משמעותי.
גודל מסד הנתונים, שמירה במטמון ודפוסי קלט/פלט
חשוב לוודא שכמות הנתונים שאתם בודקים איתה מייצגת את האפליקציה שלכם. אם יש לכם מאות גיגה-בייט או טרה-בייט של נתונים, סביר להניח שבדיקות עם כמות קטנה של נתונים לא יציגו תמונה אמיתית של הביצועים של האפליקציה. גם גודל מערך הנתונים משפיע על הבחירות שמבצע כלי אופטימיזציית השאילתות. שאילתות שמופעלות על טבלאות בדיקה קטנות עשויות להשתמש בסריקות טבלה שנותנות ביצועים נמוכים בקנה מידה גדול יותר, ולא תוכלו לזהות אינדקסים חסרים בהגדרה הזו.
חשוב לשאוף לשכפל את דפוסי הקלט/פלט של האפליקציה. היחס בין פעולות קריאה לפעולות כתיבה חשוב לפרופיל הביצועים של האפליקציה.
משך הזמן להשוואה
במערכת מורכבת, יש הרבה מידע על המצב שמתעדכן בזמן שהמערכת פועלת: נוצרים חיבורים למסד נתונים, המטמון מתמלא, נוצרים תהליכים ושרשורים. בתחילת בדיקת הביצועים, יכול להיות שהאתחול של הרכיבים האלה ינצל משאבי מערכת וישפיע לרעה על הביצועים שנמדדים אם זמן הריצה של עומס העבודה קצר מדי.
מומלץ להריץ בדיקות ביצועים למשך 20 דקות לפחות כדי למזער את ההשפעות של חימום המערכת. חשוב למדוד את הביצועים במהלך מצב יציב אחרי ההפעלה, ולמשך זמן מספיק כדי לוודא שכל ההיבטים של פעולות מסד הנתונים כלולים. לדוגמה, נקודות ביקורת במסד נתונים הן תכונה קריטית של מערכות מסדי נתונים, ויכולה להיות להן השפעה משמעותית על הביצועים. אם מריצים מדד ביצועים קצר שמושלם לפני מרווח נקודות הבדיקה, הגורם החשוב הזה מוסתר בהתנהגות של האפליקציה.
בדיקה שיטתית
כשמשפרים את הביצועים, כדאי לשנות רק משתנה אחד בכל פעם. אם משנים כמה משתנים בין הרצות, לא ניתן לבודד את המשתנה ששיפר את הביצועים. למעשה, יכול להיות ששינויים שונים יבטלו זה את זה, כך שלא תראו את היתרון של שינוי מתאים. אם השרת של מסד הנתונים נמצא בשימוש יתר, נסו לעבור למכונה עם יותר ליבות וירטואליות (vCPU) תוך שמירה על עומס קבוע. אם הניצול של שרת מסד הנתונים נמוך, כדאי לנסות להגדיל את העומס תוך שמירה על הגדרת ה-CPU.
טופולוגיה וזמני אחזור ברשת
טופולוגיית הרשת של המערכת יכולה להשפיע על תוצאות בדיקת הביצועים. ההשהיה בין האזורים שונה. כשמבצעים בדיקות ביצועים, חשוב לוודא שהלקוח ואשכול מסד הנתונים נמצאים באותו אזור כדי למזער את זמן האחזור ברשת ולהשיג את הביצועים הטובים ביותר – במיוחד באפליקציות עם תפוקה גבוהה ועסקאות קצרות, כי זמן האחזור ברשת יכול להיות מרכיב משמעותי בזמן התגובה הכולל של העסקה.
כשמשווים בין הביצועים של שתי מערכות שונות, חשוב לוודא שהטופולוגיה של הרשת זהה בשתי המערכות. חשוב לזכור שאי אפשר לבטל לחלוטין את השונות בזמן האחזור ברשת, גם באותו אזור יכולים להיות הבדלים בזמן האחזור בגלל טופולוגיות רשת בסיסיות.
כשפורסים את האפליקציה, כדאי להבין טוב יותר את ההשפעה של השהיות בין אזורים. לשם כך, אפשר להתייחס לאפליקציית אינטרנט טיפוסית עם נפח גבוה של נתונים. באפליקציה יש מאזן עומסים ששולח בקשות למספר שרתי אינטרנט שנפרסו בכמה אזורים כדי להבטיח זמינות גבוהה. יכול להיות שיהיו הבדלים בזמני האחזור בהתאם לשרת האינטרנט שמטפל בבקשה, בגלל הבדלים בזמני האחזור בין אזורים.
באיור הבא מוצגת הארכיטקטורה האופיינית של אפליקציית אינטרנט שמשתמשת ב-AlloyDB Omni. בקשות של לקוחות מטופלות על ידי מאזן עומסים, שמעביר כל בקשה לאחד מתוך הרבה שרתי אינטרנט. כל שרתי האינטרנט מחוברים ל-AlloyDB Omni. חלק מהשרתים נמצאים באזור שונה מזה שבו פועל AlloyDB Omni, ולכן זמן האחזור יהיה ארוך יותר כשמתבצעות בקשות למסד הנתונים.
מעקב אחרי ניצול המשאבים במערכת
כדי לשפר את הביצועים של מערכת מסד הנתונים, צריך לעקוב אחרי השימוש במשאבים של מערכת מסד הנתונים ושל מערכות הלקוח שמשתמשות במערכת מסד הנתונים. מעקב אחרי שתי המערכות מאפשר לוודא שמערכות הלקוח מספקות עומס עבודה מספיק כדי לקבל מדידות משמעותיות במערכת מסד הנתונים. חשוב מאוד לעקוב אחרי ניצול המשאבים של המערכת שאתם בודקים. חשוב באותה מידה לעקוב אחרי ניצול המשאבים של מערכות הלקוח שבהן אתם משתמשים כדי להפעיל את עומס העבודה. לדוגמה, אם רוצים לקבוע את המספר המקסימלי של לקוחות שמערכת מסד הנתונים יכולה לתמוך בהם לפני שנגמרים משאבי ה-CPU, צריך מספיק מערכות לקוח כדי ליצור את עומס העבודה שנדרש לניצול כל משאבי ה-CPU במערכת מסד הנתונים. לא תוכלו להעמיס על מערכת מסד הנתונים אם למכונות הלקוח שמייצרות עומס אין מספיק CPU.
בדיקות מדרגיות
בדיקות יכולת הרחבה הן היבט נוסף של בדיקות ביצועים. המושג 'מדרגיות' מתייחס לשינויים במדדי הביצועים כתוצאה משינוי במאפיין מסוים של עומס העבודה. דוגמאות למחקרים בנושא יכולת הרחבה:
- איך עלייה במספר הבקשות בו-זמנית משפיעה על קצב העברת הנתונים ועל זמני התגובה?
- איך הגדלת גודל מסד הנתונים משנה את קצב העברת הנתונים ואת זמני התגובה?
בדיקות יכולת ההתאמה כוללות כמה הרצות של עומס עבודה, שבהן משנים מאפיין יחיד בין ההרצות ואוספים ומשרטטים מדד אחד או יותר. בדיקות מהסוג הזה עוזרות לקבל החלטות לגבי צווארי בקבוק שקיימים במערכת, עומס העבודה שהמערכת יכולה לטפל בו בהתאם להגדרה ספציפית, עומס העבודה המקסימלי שהמערכת יכולה לתמוך בו וההתנהגות של המערכת כשהעומס גדל מעבר לרמות האלה.
שיקולים לגבי גודל המכונה
AlloyDB Omni מציג הרבה תכונות חדשות ל-Postgres כדי לשפר את המהימנות והזמינות של מסד הנתונים. המעקב שנדרש כדי לעשות את זה משתמש במשאבים במכונה שבה פועל AlloyDB Omni. במכונות קטנות מאוד יש מלכתחילה משאבי זיכרון ומעבד מוגבלים, ולכן לצורך השוואה, מומלץ להשתמש במכונות עם לפחות ארבע ליבות וירטואליות (vCPU).