סיפור לקוח – שיפור ביצועים מערכת מידע ברמת ארכיטקטורה

21 ביולי 2008

אין תגובות

האם אתה אוהב מערכות מהירות או איטיות?

האם ניתן לשפר ביצועים של מערכת כשהמערכת אינה קיימת עדיין? האם ניתן לצפות מראש בעיות זמני תגובה כשאף שורת קוד עוד לא נכתבה? האם ניתן לדעת מראש מה תהיה צריכת רשת, CPU וזכרון – המשאבים המרכזיים שמהווים צווארי בקבוק בדרך כלל?

התשובה – בפרוש כן, ניתן למדל את כל זה ואף מעבר לזה, כל מה שנדרש הוא לדעת לשאול שאלות נכונות.

שיפור ביצועים מתחיל בארכיטקטורה

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

  • תכנון לקוי מוביל למימוש לקוי. ארכיטקטורה ועיצוב לא נכונים תמיד יובילו לבעיות ביצועים. לדוגמה, מערכת שעוצבה להשתמש ב-Mutlithreading בצורה לא נכונה לא תעמוד בעומס, מערכת שמציגה דוחות ולא תוכננה להקטין נפחים לא תיתן זמני תגובה טובים ברשתות עם רוחב פס מוגבל. מערכת שבנויה תוך ביזור יתר שלא לצורך תהיה איטית בגלל קפיצות ברשת – SOA ו-S+S אינם פתרון פלא לכל דבר, יש להם מחיר! אלה הן דוגמאות פשוטות אך נצפות בשטח כל פעם מחדש.
  • בזבוז משאבים יקרים. ניתן לחזות בעיות ביצועים ולחסוך זמן יקר – זמן של מפתחים שבונים מערכת כושלת, זמן של מהנדסי בדיקות ביצועים שמבצעים בדיקות ביצועים על מערכת כושלת, זמן של בודקי QA שמבזבזים זמן על בדיקת תרחישים במערכת שמגיבה לאט, זמן של יועצים שחייבים לזהות את הבעיה ולהצביע עליה וגם למקורה כולל דרך לפתרון, זמן של מפתחים שצריכים לקודד מחדש.
  • פגיעה תדמיתית. לקוח שמקבל מערכת יפה מבחינת עיצוב גרפי אך לא מספקת “סחורה” יחשוב פעמיים בפעם הבאה אם להזמין מאותו הספק – סקסי לא תמיד תחליף טוב לביצועים טובים (זה גם תופס בתחומים אחרים…, לדוגמה, פרסום – ראה טיפ #3).

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

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

מה שואלים?

כדי להיות שיטתי וכתוצאה מכך להיות תוצאתי ויעיל נדרשת גישה פשוטה אך מקיפה. לגישה הזו אנחנו קורים מסגרת שיפור ביצועים – Performance Frame. מסגרת שיפור ביצועים נוצרה ע”י קבוצה patterns & practices (ובפרט ע”י J.D. Meier שמוביל את המאמץ) כתוצאה מפעילות מחקר מקיפה והשקעת משאבים אדירים. המחקר כולל ידע שנצבר בקבוצות מוצרי מיקרוסופט, בצוותי יעוץ מיקרוסופט – MCS (להזכירך – הבלוג הזה הוא של MCS), ומומחי שיפור ביצועים עם שם עולמי. המסגרת כוללת קטגוריות של הנושאים שמשפיעות הכי הרבה על ביצועים של המערכת, הינה המסגרת:

Performance Frame

לרשימה המלאה גלוש כאן – Performance Frame

סיפור לקוח

לקוח Enterprise מתכנן לבנות מערכת אינטרנט למתן שירות ללקוחות עסקיים. נבנתה ארכיטקטורה על. לאור נסיון העבר הוחלט לתקוף נושא שיפור ביצועים בשלבים מוקדמים. אלה הצעדים שבוצעו בשלב הארכיטקטורה והתוצאות שהניבו:

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

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

עשה זאת בעצמך (לא צריך ללכת ל-ACE או קנה ובנה)

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

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

קריאת המשך

Alik Levin 
שמי אליק לוין ואני מתרכז ב- Security and Performance באפליקציות Net.
בזמני הפנוי אני בלוגר שרוף.
הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים