כשמציגים בתרשים את קצב העברת הנתונים לאורך זמן בזמן שמשתנה אחר משתנה, בדרך כלל רואים שקצב העברת הנתונים עולה עד שהוא מגיע לנקודה שבה המשאבים נגמרים.
האיור הבא מציג גרף אופייני של קנה מידה של תפוקה. ככל שמספר הלקוחות גדל, עומס העבודה והתפוקה גדלים עד שכל המשאבים מוצו.
באופן אידיאלי, כשמכפילים את העומס על המערכת, גם התפוקה אמורה להכפיל את עצמה. בפועל, תהיה תחרות על המשאבים שתגרום לעלייה קטנה יותר בנפח הנתונים. בשלב מסוים, מיצוי משאבים או מחלוקת על משאבים יגרמו לרוחב הפס להתייצב או אפילו לרדת. אם אתם מבצעים אופטימיזציה של קצב העברת הנתונים, חשוב לזהות את הנקודה הזו כי היא תעזור לכם להבין איפה כדאי לבצע שינויים במערכת האפליקציה או במסד הנתונים כדי לשפר את קצב העברת הנתונים.
הנה כמה סיבות נפוצות לכך שקצב העברת הנתונים מתייצב או יורד:
- מיצוי משאבי CPU בשרת מסד הנתונים
- ניצול יתר של משאבי המעבד (CPU) בצד הלקוח, כך שלא נשלחת עוד עבודה לשרת מסד הנתונים
- תחרות על נעילה במסד הנתונים
- זמן ההמתנה לקלט/פלט כשהנתונים חורגים מהגודל של מאגר הנתונים הזמני של Postgres
- זמן ההמתנה של קלט/פלט בגלל ניצול מנוע האחסון
- צווארי בקבוק ברוחב הפס של הרשת שמונעים החזרת נתונים ללקוח
זמן האחזור והתפוקה הם ביחס הפוך. ככל שזמן האחזור גדל, קצב העברת הנתונים יורד. זה הגיוני מבחינה אינטואיטיבית. כשצוואר בקבוק מתחיל להיווצר, הפעולות מתחילות להימשך זמן רב יותר והמערכת מבצעת פחות פעולות בשנייה.
בתרשים של קנה המידה של זמן האחזור אפשר לראות איך זמן האחזור משתנה ככל שהעומס על המערכת גדל. החביון נשאר יחסית קבוע עד שמתרחשת בעיה בגלל תחרות על משאבים. נקודת הפיתול של העקומה הזו בדרך כלל תואמת לנקודה שבה עקומת התפוקה משתטחת בתרשים של קנה המידה של התפוקה.
דרך שימושית נוספת להערכת זמן האחזור היא באמצעות היסטוגרמה. בייצוג הזה, אנחנו מקבצים את זמני האחזור לקטגוריות וסופרים כמה בקשות נכללות בכל קטגוריה.
בהיסטוגרמה הזו של זמני האחזור, רוב הבקשות הן מתחת ל-100 אלפיות השנייה, וזמני האחזור ארוכים מ-100 אלפיות השנייה. הבנת הסיבה לבקשות עם זמני האחזור הארוכים יותר יכולה לעזור להסביר את השינויים בביצועי האפליקציה. הסיבות לזנב הארוך של זמני האחזור הארוכים יותר תואמות לזמני האחזור הארוכים יותר שמופיעים בתרשים הרגיל של קנה המידה של זמן האחזור, ולשיטוח של תרשים התפוקה.
ההיסטוגרמה של זמן האחזור שימושית במיוחד כשיש כמה אופנויות באפליקציה. מודאליות היא קבוצה רגילה של תנאי הפעלה. לדוגמה, ברוב המקרים האפליקציה ניגשת לדפים שנמצאים במטמון המאגר. ברוב המקרים, האפליקציה מעדכנת שורות קיימות, אבל יכולים להיות כמה מצבים. לפעמים האפליקציה מאחזרת דפים מהאחסון, מוסיפה שורות חדשות או נתקלת במאבק על נעילה.
כשאפליקציה נתקלת במצבי הפעלה שונים לאורך זמן, ההיסטוגרמה של זמן האחזור מציגה את המצבים השונים האלה.
באיור הזה מוצג היסטוגרמה בימודלית טיפוסית שבה רוב הבקשות מטופלות תוך פחות מ-100 אלפיות השנייה, אבל יש עוד קבוצת בקשות שלוקח 401-500 אלפיות השנייה לטפל בהן. הבנת הסיבה להופעת האופן השני יכולה לעזור לשפר את הביצועים של האפליקציה. יכולים להיות גם יותר משני אופנים.
המודאליות השנייה יכולה לנבוע מפעולות רגילות של מסד הנתונים, מתשתית ומטופולוגיה הטרוגניות או מהתנהגות של האפליקציה. הנה כמה דוגמאות שכדאי להביא בחשבון:
- רוב הגישות לנתונים הן ממאגר המאגרים של PostgreSQL, אבל חלקן מגיעות מהאחסון
- הבדלים בזמני האחזור ברשת בין חלק מהלקוחות לבין שרת מסד הנתונים
- לוגיקה של אפליקציה שמבצעת פעולות שונות בהתאם לקלט או לשעה ביום
- תחרות על נעילה באופן ספורדי
- עלייה חדה בפעילות הלקוחות