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