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