חוויות מכנס ביצועים 2011 התשע"ב אי שם

29 בדצמבר 2011

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


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


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


בשלב הבא עלה על הבמה יאיר הורוויץ מ HP והציג את ה Performance Center 11 של HP. ה Performance Center זה גירסת ה Enterprise של Load Runner. אחת התוספות החזקות של הגירסה החדשה היא הקישור ל ALM, מה שמשלב את המערכת בצורה מלאה בכל תהליך הפיתוח. דבר חשוב נוסף הוא מעבר מהסתכלות פרטנית, להסתכלות מערכתית, של בעיות הביצועים. שילוב דרישות הביצועים ברמת הארגון ולא ברמת הפרויקט. בנוסף כל הצעצועים הצפויים, כמו תיזמון בדיקות בשעות שאין משתמשים, חלוקת משאבי בדיקות בין הבדיקות השונות וכו.


לאחר מכן עבר יאיר לדבר על ה Sire Scope, שהוא כלי לאיסוף רציף של מידע וניטור מערכות. החוזקה שלו היא שהוא מכיר את כל המערכות ולא רק את עולם המיקרוסופט, כך שאם יש לך מערכת הטרוגנית, ויש לך כמה ספקים, ומערכות כמו WebSpare של IBM ו מערכות Enterprise של Oracle בארגון. אתה מקבל את היכולת לנטר את כולם בנקודה אחת. וכמובן הוזכרו גם SLA, Tranding, Analysys ו Diagnostics ואפילו BSM.


הפנינה שתרם לי יאיר, היא הסיפור של השימוש בפיצה לבדיקת עומסים. פעם כדי לעשות בדיקות ביצועים, היו מרכזים את כל העובדים עם המחשבים שלהם בחדר אחד. קונים לכולם פיצה, על מנת להבטיח שכולם יגיעו. ואז מבקשים מהם שכולם ביחד, באותו רגע, ילחצו על ה Enter. כדי לייצר עומס על המערכת. ה Load Runner הוא סך הכל שיפור של התהליך, בזה שהחליף את המשתמש הפיזי במשתמש וירטואלי. ובכך חסך את תקציב הפיצה הארגוני.  כמובן ש Load Runner נותן היום הרבה יותר ממשתמש וירטואלי, ויאיר לא שכח להזכיר את הפרוטוקולים החדשים שנוספו, כמו למשל תמיכה מלאה ב AJAX, הסתכלות ברמת ה UI באמצעות TruClient ולא רק ברמת ה Web Transport והקורולציות (דורש בשלב זה Fire Fox).


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


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


אז להלן רשימה של כללים (עשרת הדברות) שהוצגו: עובד לאט, לא עובד – ברמת הפרט, לא עובד מהר לא עושים לקוד Check In.  לא ניגשים ל DB בלולאה. לפני הפיתוח לתקף הנחות יסוד וארכיטקטורה, ואם צריך תייצר לצורך זה אבטיפוס. תימנע מ Join – ים רבים, גם אם זה אומר שצריך לעשות Denormalization ל DB. כל מה ששואלים עליו בכמויות גדולות, תדאג שיאונדקס. אל תשתמש ב PL/SQL כלוגיקה עיסקית ואל תכתוב שם קוד. אם אתה כותב קוד PL זה כנראה דבר רע. עדיף לשאול שאלה שמביאה Raw Data ואת העיבוד של הלוגיקה העיסקית לעשות בזכרון של המחשב, עם קוד בשפה נורמאלית שניתנת ל Debug ולניהול. עבודה עם ORM ועם אוביקטים, תמיד תהיה יותר קלה לכתיבה מאשר שימוש ב SQL עם שאילתות מורכבות וכתיבת לוגיקה תכנותית בשפה שאינה פרוצדורלית. לעבוד במנות גדולות יותר טוב מעבודה ברמת רשומה בודדת, גם אם הנצילות לא מלאה.


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


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


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


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


לאחר ארוחת הצהריים היה פיצול נוסף ואנשי ה Java נפרדו מאנשי ה NET. והלכו לשמוע משי כהן מאורקל ישראל, מה מציעה אורקל בתחום. כאשר באותו זמן, אנשי ה DB, שמעו על ניתוחי ביצועים בזמן אמת, מליאור סבג מאורקל ישראל. לומר את האמת, אם הייתי פנוי, הייתי הולך לשמוע את שי, אבל מה לעשות, וזה היה חריץ הזמן שבו אני הרצתי על הנושא האהוב עלי Production Dbugging.


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


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


הסתבר שהמערכת המדוברת מתבססת המון על Java Script, ואני חייב לומר מראש, ש Java Script זה לא היה אף פעם My Cup of tee. אבל מעניין אותי תמיד לשמוע על תקלות, בעיות, ובעיקר איך עלו עליהם, ואיך פתרו אותם. בהרצאה הוצגו הכלים FireBug ו IEDevTools שהם ספציפיים לדפדפן, ומאפשרים צפיה ב DOM, ביצוע Debug של Java Script, שינוי דינמי של Poperties וכו'. בהרצאה הוצגה דוגמא ספציפית איך שימוש בכלים הללו עזר לפתור בעיה. אחר כך הוצג  Fiddler, עם בעיה אחרת ברמת התקשורת בין הדפדפן לשרת, שהוא סיע לפתור. ולסיום הוצג DynaTrace AJAX, עם דוגמאות לבעיות שנפתרו בעזרתו.


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


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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

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