שיפור ביצועי הקוד והיעילות

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

לצורך הארכת חייה של המערכת עלינו להציב את מיטב מוחות הארגון למשימת תחזוקתה ושיפור ביצועיה. אך DBA מקצועי ככל שיהיה יעמוד מול שוקת שבורה אם לא יקבל את מיטב הכלים לביצוע משימתו. אלפי הנתונים המספריים אודות פעילות בסיס הנתונים מהווים ערמת שחט ללא כלי חזק המפרש אותם לשפת אדם.

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

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

ארגונים אשר התקינו את תוכנות שיפור הביצועים על בסיס הנתונים שלהם מדווחים בממוצע על ירידת משך המתנת המשתמש לתגובת המערכת בכ- 70%. שיפור אשר מבטיח לדעת כל את הצלחת מערכת המידע בארגון, ומעל הכל את הישארותה באוויר לאורך זמן תוך הקטנת הצורך בשדרוגים רבים, ברמת התוכנה וכן ברמת החומרה.

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

תוכנות שיפור הביצועים הקיימות כיום בשוק פותחו ע"י שלוש חברות: Oracle, Precise ו- Quest. הנפוצה והמובילה ביניהן היא תוכנת Precise SQL של חברת Precise, אשר ממקמת בין לקוחותיה המרכזיים את חברת Oracle העולמית. עובדה המלמדת אותנו רבות על מידת יעילותה אל מול מתחרותיה. החברה הנה שיתוף פעולה ישראלי-אמריקאי אשר מוכיח שוב את מידת כשרון המוחות הישראלים בעולם.

יעילות קוד במערכת

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

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

התרשים הבא המפרט את יעילות שיפור הביצועים מול העלות לאורך שלביו השונים של הפרוייקט:

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

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

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

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

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

בהצלחה