ניטור ביצועים – מתי זה באמת קריטי?

כנראה כל מי שעבד אי פעם מול מחשב מכיר את התופעה של בעיית ביצועים – המשתמש מחכה, ומחכה ומחכה בזמן שהמחשב עסוק במשהו, לא תמיד ברור במה אבל זה בטח משהו חשוב… או שלא?

במערכות מידע רבות, בייחוד כאלו שפותחו בבתי תוכנה קטנים יחסית ודלי משאבים, נוטים בדרך כלל לייחס חשיבות רבה מאד לממשק המשתמש של המערכת, לפיתוח התהליכים העיסקיים המהווים את לב המערכת ושאר המשאבים בד"כ מופנים כלפי Troubleshooting של בעיות שקיימות במערכת. כמובן שהסיבה לכך ברורה – עסקים רבים בוחרים מערכות מידע על פי נוחות ממשק המשתמש שלהן, רמת השירות של צוותי התמיכה של בית התוכנה ורמת התמיכה של המערכת בתהליכים העיסקיים של בית העסק.

למרות ששיקולים אלו הינם שיקולים לגיטימיים וטובים לבחירת מערכות מידע, קיים שיקול נוסף חשוב לא פחות – עד כמה מערכת המידע משקיעה בטכניקות לניטור ביצועיה. בעל עסק עלול לטעון, במידה מסויימת של צדק – "למה זה צריך לעניין אותי? אם תהיה בעיית ביצועים אני אפנה לתמיכה של בית התוכנה ושהם יפתרו לי את הבעיה…" מתברר שלמרות שטענה כזו מוצדקת לחלוטין אין לה ממש אחיזה במציאות, מאמר זה יסביר מדוע וכיצד ניתן לפתור את הבעיה.

במקרה של בעיית ביצועים, הבעיה נובעת תמיד מאותה בעיה: התשתית (קרי דיסקים, זכרון, מעבד או רשת) אינם מצליחים לספק את דרישות המערכת. כלומר, אם המערכת פועלת לאט (ובמיוחד אם לפעמים היא עובדת מהר מספיק) היא כנראה ממתינה למשהו או למישהו. כל שיש לעשות הוא אחת מ-2: (או שילוב של שניהם במידה כלשהי) 1. הגדלת יכולות התשתית הרלוונטית – במידה והמערכת ממתינה למעבד שיתפנה, למשאבי זיכרון, דיסקים או לתגובה משרת רשת כלשהו, ניתן להוסיף מעבדים, זיכרון או להגדיל את מהירות הדיסקים או כמות הדיסקים ב-RAID או אפילו לשדרג את מהירות הרשת.
2. הקטנת הדרישה של המערכת – ניתן, ע"י ייעול קוד התוכנה לחסוך פניות לעיבוד, קריאות לדיסקים ואף לצמצם את נפחי המידע המועבר ברשת.

אך אליה וקוץ בה, במדה וקוד התוכנית אינו יעיל דיו ייתכן בהחלט מצב שבו אף שרת לא יהיה חזק מספיק להריץ אותה במהירות מספקת, חשוב להבין שגם אם המערכת עובדת במהירות מספקת לעיתים, עדיין אין זאת ערובה לכך שהקוד יעיל מספיק – גם קוד שאינו ייעיל יכול לעבוד באופן סביר במקרה שכמות המשתמשים או כמות המידעים או מבנה המידעים הוא כזה או אחר. מצד שני, שדרוג של שרת חייב להיות ממוקד (למשל – שדרוג זיכרון, שדרוג מעבד, שדרוג הדיסקים או שדרוג תשתית הרשת.) ומדוייק (לאיזו תצורה רוצים להגיע) משום שאחרת, ייתכן ונשדרג רכיב זה או אחר ועדיין לא נגיע לתצורה מספקת, למרות שרכיבי החומרה היום זולים מאי פעם ייתכן בהחלט שבאופן כזה ייגרם בזבוז עצום.

אז מה הפתרון? הפתרון למעשה נעוץ בניתוח של הרגעים שבהם המערכת עובדת באופן תקין או סביר, ברגע שבונים כלי ניטור המודד את נתוני ביצועי השרת (במושג של משכי זמן לפעולות במערכת שמשך ביצוען יחסית קבוע), מדדי צריכה (כמות המשתמשים במערכת, כמות החומר המעובד וכו'), מדדי תפקוד רכיבי השרת השונים (מעבד, זיכרון, דיסקים ורשת) ונתוני פעילות המערכת (למשל רשימת השאילתות המתבצעות). במידה ומשתמשים בכלי כזה למשך פרק זמן ארוך מספיק יהיה ניתן לאתר את המרכיב הבעייתי או לכל הפחות לזהות דפוסי התנהגות של המערכת וכך בעצם להשיג מידע לגבי מתי וכיצד מופיעה האיטיות ולא פחות חשוב – מה קרה במערכת בזמן האיטיות.

למעשה, נסיונות לאתר בעיות ביצועים ע"י בהייה ב-Performance Monitor וחיפוש ערכים גבוהים של CPU, זיכרון, דיסק או רשת פעמים רבות לא משיגים את התוצאה וזאת משום שבמקרים רבים העומס על כל אחד מהרכיבים אינו גבוה באופן אבסולוטי, אלא גבוה יותר ביחס לפעמים אחרות בהן המערכת עבדה כשורה.

לעיתים רבות, בעיות ביצועים עשויות להתחיל באיטיות ולהגיע לבעיות של ניתוקים (עקב הודעות Timeout) זאת משום שבמערכות רבות (למשל ODBC) מוגדרת הגדרה המורה לרכיב ה-Client "להתיאש" לאחר פרק זמן מסויים (למשל: ב-ODBC Client של מערכת MS Access מוגדרת בברירת המחדל תקופת זמן בת 60 שניות). במקרים כאלו, כתוצאה מגידול טבעי בכמות הנתונים פניות שעד כה נמשכו כ-50 שניות, עשויות במשך הזמן לגדול ל-60 ולהגיע למשכי זמן אף ארוכים יותר ולגרום לתחנה לוותר בטענת Timeout. כך שגם בעיות של ניתוקים עשויות להיות סוג של בעיות ביצועים.