הרצאה 9 - קורס Load Runner הראשון
פרקי ההרצאה: הרצאה 9 - קורס Load Runner הראשון
תמלול ההרצאה: הרצאה 9 - קורס Load Runner הראשון
הטקסט המלא של הדקות הראשונות בהרצאה «הרצאה 9 - קורס Load Runner הראשון» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום, ערב טוב לכם, אנחנו מתחילים בשיעור השביעי בנושא בדיקות עומסים ולואוד ראנר ואני רואה שההקלטה תחילה ועובדת, קובץ גדל אז אנחנו יכולים לרוץ עם המצגת. זאת המצגת שלנו להיום והנושא שאנחנו נדבר עליו הוא נושא של ה-results analysis, ניתוח תוצאות.
למעשה מה שעשינו עד היום זה יצרנו את הסקריפטים, תכננו את הבדיקות העומסים, הגדרנו מה דרישות המערכת, מהי מטרת הבדיקות, כמה יוזרים להריץ, בנינו את הסצנריו, הרצנו את הסצנריו בשיעור האחרון, הגדרנו את המוניטורינג, מדדנו את כל המשאבים של המערכת וסוף סוף אנחנו בשלב של ניתוח התוצאות.
מה אנחנו נדע לעשות היום? זה בעצם להיכנס לאפליקציה נוספת, אפליקציה רביעית שאנחנו מכירים, אפליקציה שלישית שאנחנו מכירים והכלי הרביעי מתוך כלים של לואוד ראדר, אני מזכיר לכם את השמות, זה קונטרולר, וירצ'יאל יוזר ג'נרייטור, לואוד ראדר ג'נרייטור ואנלייזר.
הכלי שאנחנו נעבוד עליו היום זה אנלייזר, הכלי שמאפשר לנו לנתח את התוצאות. אוקיי, הרצנו את התוצאות, יש לנו את ה-Web Server, יש לנו את ה-Database, יש לנו firewallים, את כל סדרת המערכות, את כל הארכיטקטורה שאנחנו הגדרנו ויש לנו איזשהו כשל, כשל תוך כדי ריצה או שאנחנו לא עובדים בזמנים או שיש לנו זמן תגובה גבוה ואנחנו
צריכים להבין מאיפה מגיעה הבעיה. כדי לנתח את התוצאות אנחנו ניקח את התוצאות של הקונטרולר וניכנס שלב שלב וננסה להבין כיצד מנתחים את התוצאות.
אז קודם כל נסתכל אם יש לנו בכלל טרנזקציות גבוהות, אם יש לנו זמן תגובה גבוה. במידה ואנחנו מגלים שהכל בסדר, אז יכול להיות שבזה אפשר לסיים את התוצאות ולהגיד, אוקיי, המערכת עומדת בזמנים, המערכת עומדת בעומסים, אין טעם בכלל להיכנס הלאה.
במידה וגילינו איזושהי בעיה בזמן תגובה, אנחנו נעשה drill-down פנימה, נצלול פנימה וננתח את המשאבים של המערכת. משווים של ה-Web Server, משווים של ה-Database, משווים של ה-Client.
ואם גילינו שם את הבעיה, אז נתחיל בעצם לעשות הצלבת נתונים, לבדוק באמת את המדידות ולגלות את הדברים הנוספים. ככה נראית תוצאה של ההרצה הרגילה, כל הרצה.
אתמול באזור הזה אתם רואים את כל הריפורטים האפשריים שאפשר להפיק מההרצה, בצד הימין זה בעצם הייתוח של אותם הריפורטים. יש גם מה שנקרא Summary Report שמאחד בתוכו את כל הנתונים ברמת-על והוא מדבר קודם כל על הטרנזקציות.
איזה טרנזקציות קיימות אצלנו, מה אנחנו מדדנו? קרדיט, לוג-אין, לוג-אאוט, סרצ' וכן הלאה. מה הזמן התגובה הכי גבוה שהיה לאותה טרנזקציה?
ואותו אנחנו מסתכלים. את הזמן תגובה הזה אנחנו מחפשים. כמובן גם מעניין אותנו כמה טרנזקציות נכשלו, למה לוגאוט נכשל, זה משהו שכדאי לנו לנתח. וגם Average זה משהו שהוא נתון מעניין אבל לא הייתי מסתמך עליו, בדרך כלל הוא לא מצביע על הרבה דברים, לעומת זאת 90% הוא אומר מה הזמן שהיה עבור 90% מהטרנזקציות.
למה 90%? כי לפעמים 10% אלה הטרנזקציות שאפשר להזניח אותן, אפשר להוציא אותן ללידוך, יכול להיות שהן קרו תוך כדי לוגין, שבאמת היה לוגין גבוה, או יכול להיות שתוך כדי לוגאאוט או עוד סיבה אחרת היה איזשהו כשל ידוע במערכת.
אז 90% זה משהו שהוא טוב למערכות הלא קריטיות, לא מבצעיות, מערכות שאפשר לחיות עם הכשל בזמן התגובה גבוהה.
חיים יבקשו מכם 99% או 99.9% תלוי תלוי במערכת תלוי בדרישות תלוי במדינה שאתם עובדים בה כל מדינה עם הדרישות שלה כל הארגונים ודרישות שלו בדרך כלל אחרי שאנחנו נפתח את הקריפט שלנו את התוצאות הריצה שלנו אנחנו נעבור גם ל-Average Response Time ל-Average Transaction Response Time
אני חוזר לגרף הקודם ולשקף הקודם כדי להראות לכם שזה מופיע כאן, אוקיי? מה שנעשה כרגע, אני אעצור בשלב הזה כי אני רוצה להראות לכם את הדברים בלייב, איך הם קיימים בתוך המערכת.
אז בואו ניכנס, קודם כל הדרך להגיע לאנליזר היא קיימת בתוך האפליקיישן ואפשר לבחור את האנליזר ודרך נוספת היא לבוא ישירות מתוך הקונטרולר. אז בואו ניתן לזה לעלות, ככה נראית בעצם הכניסה לתוך האנלייזר.
אם אנחנו רוצים עכשיו לקחת איזשהו דוח קיים, אנחנו נפתח אותו מכאן, ונבחר את הקובץ המתאים. אני רוצה להראות את הדרך הנוספת, שהיא בדרך כלל תהיה יותר מקובלת, זה לבוא מתוך הקונטרולר.
אנחנו מגיעים לקונטרולר, הנה זה הקונטרולר שלנו, עולה, פה נבחר איזה משהו, נעשה קנצר קודם כל, לא משנה. כאן זה הדרך הנוספת להגיע לתוצאות.
אני לא הכנתי מראש את התוצאות של הריצה, אני רוצה שנעשה את זה ביחד אתכם. בואו נקצור קריפט חדש של ה-search of flight order, כמו שעשינו בשיעור הקודם. אנחנו נקבע שאנחנו עובדים עבור 20 יוזרים, זה בסדר גמור לנו.
אנחנו נריץ את זה כדי לקצר את התהליך לא 5 דקות אלא 1 דקה ואני חושב שזה מספיק לנו כדי להתחיל בריצה. אה, כמובן, כמובן שכחנו את הלואוד ג'נרייטור.
לואוד ראנר אייג'ן, סליחה. ונעשה קונקשן אליו, נגיד לוקל-הוס. ונתחיל בריצה. ונמתין דקה. אין לנו ברירה אלא להמתין דקה.
בזמן הזה אנחנו נבדוק אם הקובץ שלנו גדל, של ההקלטה, וזה טוב לנו. כמובן יש לנו נפילות של המערכת ואנחנו יודעים, אבל זה פחות קריטי לנו ואנחנו יכולים לחיות עם זה.
עברו כבר 30 שניות, יש לנו עוד המתנה של 30 שניות, אז בואו נמתין. זהו, אני חושב שאנחנו בשלב של תיום ההרצה, עוד כמה שניות זה יסתיים, ואז נוכל לנתח את התוצאות. בואו נעצור את ההרצה כדי שזה יזרז את התהליך.
האם לעצור? כן. אם יוצאים באופן הדרגתי, כמו שאתם רואים, זה עוד זמן שמאריך לנו קצת, הנה, ונאספו התוצאות עכשיו. עכשיו, בהודעה שראיתם, כל התוצאות עברו מתוך ה-loadrunner agent לתוך ה-controller.
במקרה שלנו ה-loadrunner agent רץ על העמדה, אבל במקרים שהוא לא רץ על העמדה זה ממש יעבור כתעבורה ברשת ל-controller. ומה אפשר לנסות לעשות?
זה בעצם לפתוח אנליזיס. בואו נעשה את זה. אני מקווה שהתהליך הזה יצליח, הוא לוקח קצת זמן. הנה, מעלה לנו את האנליזר.
התהליך הזה לא הכי קל בעולם האם הוא הצליח אני רואה שזה עדיין לוקח קצת זמן הוא רק הראה לנו את האנליזר אבל לא הראה לנו שום תוצאות אז בואו נתחיל לחקור את הסיבות בואו נבחר את האנליזר הזה יכול להיות שאני רק פתחתי את האנליזר בלי להגיד לפתוח את התוצאות למעשה התבלבלתי בין שני כפתורים שמאוד דומים אחד לשני
אחד אומר תעלה את ה-load analyzer והשני אומר תחת התוצאות הנה, זה משהו שנראה קצת יותר טוב עכשיו יפה, עוד זמן שלוקח לעלות יחסית תהליך זריז אבל במקרה הזה אולי בגלל שזה רץ על אותה עמדה אצלי ועמדה לא חזקה זה לוקח טיפה זמן כמה שניות, עוד 5% וסיימנו The following graphs were not created, hit per second and throwput.
כנראה זה פשוט, אם לא הספיקו, המערכת לא הספיקה לאסוף את התוצאות, ואולי סיבה נוספת, פשוט שכחתי להעלות את ה-WebServer שלנו, הקבוע, שאנחנו בדרך כלל מעלים, ואתם בהרצאה שלכם פשוט אל תשכחו לעשות את הדבר הזה, ואז כמובן המערכת לא עבדה מול האפליקציה האמיתית אלא סתם אספה את הנתונים.
אוקיי, סאמרי ריפורט. בואו נראה האם הוא דומה למה שראינו במצגת. הנה, יש לנו פה כמה טרנזקציות. כמובן, זה לא הספיק לאסוף את הנתונים, אמנם זה יש לנו את ה-failed.
אם הוא היה אוסף נתונים היה לנו גם מקסימום. יש לנו running ו-users, גרף של היוזרים, כמה הם הספיקו להיכנס למערכת וכמה הם רצו.
Transaction summary, תוצאות, ו-average response time. עבור in it, אוקיי? עכשיו, זו הדגמה של מה אנחנו יכולים לקבל ב-Analyze.
בואו נחזור למצגת. Average Transaction Time בדרך כלל יגיד לנו כמה זמן בציר Y, לדוגמה בציר הזה, הנחי, יש לנו זמן תגובה.
וכאן אתם רואים באיזה שעה זה קרה. אז קודם כל אפשר לראות שב-10 דקות הראשונות הזמן תגובה יחסית נמוך. גם בשעות האלה, עד 20 דקות הזמן תגובה היה סביר, זאת אומרת, אם אנחנו מגדירים באופן תיאורטי שהזמן תגובה הוא צריך להיות עד חמש שניות, אז בשלב הזה הכל נראה תקין.
ואחרי 20 דקות הזמן תגובה מתחיל לעלות, במיוחד עבור טרנזקציה ירוקה שהיא קרדיט לדוגמה. הנה הטרנזקציה הזאת שהיא מאוד מאוד גבוהה, ואנחנו הגדרנו זמן תגובה עד חמש שניות.
משהו לא תקין. איך אנחנו נגלה מה הבעיה כאן? אנחנו כנראה נצטרך לעבור לגרף הבא. ובואו נראה מה הגרף הבא שלנו. בואו נראה שיש לנו זמן תגובה ונראה אותו עבור כמה יוזרים זה קרה.
נניח והכמות המקסימלית של היוזרים שאנחנו מצפים לה היא 100 יוזרים ואנחנו רוצים שהעומס שנעמוד בו הוא יהיה 100 יוזרים כאשר זמן התגובה יהיה פחות מחמש שניות אנחנו יכולים להגיד ולהצביע על זה שברגע שאנחנו מתקרבים ל-70 יוזרים הזמן התגובה מתחיל לעלות.
אתם רואים? זה האזור. זאת אומרת שהמערכת שלנו עומדת ב-70 יוזרים והיא לא מצליחה לעמוד ביותר מ-70 יוזרים עם הזמן תגובה הצפוי.
מה לעשות, אנחנו נצטרך להתמקד בנתונים נוספים כדי להבין מה הסיבה לאי-עמידה בזמן תגובה שלנו. בדרך אנחנו יכולים להגיד כמה אחוז מהטרנזקציות לא עמד בזמן תגובה צפוי.
זה הזמן תגובה, הציר העופקי כמו שראינו, הוא צריך להיות חמש שניות, בערך חמש שניות. יכולים להגיד שרק 60% מהטרנזקציות עמדו בזמן תגובה הזה, ומשלב הזה קרוב ל-40% מהטרנזקציות פשוט לא עמדו בזמן.
מה עוד סוגרף שאנחנו יכולים להביא ושיעזור לנו קצת לנתח ולהתמקד בתוצאות? זה Transaction Response Time Distribution. מה זה אומר? שאם ניקח Transacted Credit, אנחנו מתמקדים כרגע ב-Transacted Credit, כנראה שעשינו drill-down פנימה רק לטרנזקציה הזאת.
אפשר להגיד שרוב הטרנזקציות עמדו בזמן תגובה טוב, זאת אומרת, קרוב לאפס שניות מיידית קיבלנו כמעט 800 טרנזקציות, 758. בחמש שניות עמדו 37 טרנזקציות, זאת אומרת, זה כמות טרנזקציות אבסולוטית.
אבל כל האזור הזה זה אזור עם טרנזקציות וזמן תגובה גבוה, וזה גם משהו שיכול להצביע לנו על התנהגות של המערכת שלנו. אוקיי, אנחנו היינו בפנים, ראינו את הבעיות, בואו נעשה קצת ניתוח יותר מעמיק, קצת יותר נאסוף מידע.
ולואוד ראנר הוא באמת מאפשר לעשות אין סוף אפשרויות, אין סוף פעולות במערכת שלנו, קורלציות, drill-down, בואו נראה איך זה מתבצע במערכת. היא מעלה חזרה את ה-loadrunner-analyzer כמו שאתם רואים חזרנו חזרה ובואו נעבור קצת על האופציות שאפשר לעשות כאן קודם כל יש לנו פה פלוס ומינוס אנחנו יכולים להוסיף new graph
נגיד מעניין גרף מתוך האזור של הטרנזקציה מה יכול לעניין אותנו