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