האצת יישומים: ביצועים מהירים יותר עבור משתמשי הקצה

על ידי צוות Techopedia, 2 בנובמבר 2016

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

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

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

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

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

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

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

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

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

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

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

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

לאחר שאמרתי את זה, אעבור לדז שידבר על משהו אחר לחלוטין, בתקווה.

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

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

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

מה קרה? ובכן, בשנת 1996, אפליקציות המונעות על בסיס נתונים הוסבו עם תנופת האינטרנט. רבים מאיתנו עברו את זה. גם אם לא היית סביב הפריחה באינטרנט, אתה יכול פשוט להסתכל סביבך ולהבין שבחיי היומיום, שאנחנו מחברים הכל לאינטרנט עכשיו. אני מאמין שיש לנו טוסטר שכנראה מגיע עם האפשרות להיכנס ל- Wi-Fi וזה מגוחך, מכיוון שאני לא זקוק לטוסטר שלי שמחובר לאינטרנט. בשנות האלפיים, ובמיוחד בתחילת שנות האלפיים, היינו צריכים להתמודד עם הצמיחה האדירה הזו בסבב המורכבות המספקת ביצועי שירות בפריחת דוט-קום. ואז עוד ניצוץ מגושך ומגוחך ברשת 2.0, שם הגיעו סמארטפונים וכעת יישומים היו בידינו 24/7 ותמיד היו במצב.

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

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

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

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

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

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

בואו נסתכל על כמה אנכיים. בוא ניקח לדוגמא שיווק. להלן תרשים דומה אך מערימות הטכנולוגיה הזמינות בטכנולוגיית השיווק בלבד. זהו הגרף משנת 2011. להלן גרסת 2016. רק תחשוב על זה, זה רק מספר המותגים של מוצרים שאתה יכול להפעיל עבור טכנולוגיה בכל הקשור לטכנולוגיה שיווקית. לא המורכבות של המערכות בפנים, לא האפליקציה והאינטרנט והפיתוח והרשת וכל השאר. רק המותג. יש לפני, חמש שנים והנה היום. זה רק הולך ומחמיר. אנו נמצאים בנקודה זו בה המציאות היא, בני אדם פשוט לא יכולים להבטיח את כל ההסכמים ברמת השירות. איננו יכולים לצלול לפרטים מספיק, מספיק מהר ובקנה המידה שאנו זקוקים לו. הנה דוגמה למראה קונסולת ניטור כעת. זה כמו כמעט עשרים ומסכים מוזרים מודבקים זה בזה ומעמידים פנים שהם מסך אחד גדול ומוקרן שמוקרן אחר כל יצירה קטנה. עכשיו זה מעניין כאן, לא אזכיר את המותג, אבל פלטפורמת הניטור הזו עוקבת אחר יישום יחיד בסביבת לוגיסטיקה ומשלוח. רק אפליקציה אחת. אם אתה חושב על מה רובין דיבר איפה ארגונים יכולים להחזיק 40, 000 מסדי נתונים עכשיו בסביבות ייצור. האם אתה יכול פשוט לדמיין כיצד 40, 000 גרסאות לאוסף המסכים הזה שעוקב אחר יישום אחד יכול להיראות? זה עולם אמיץ מאוד שאנחנו חיים בו. כמו שרובין אמר ואני בהחלט, 100 אחוז מהדהדים שבלי הכלים הנכונים, בלי התמיכה הנכונה והאנשים השולחן על השולחן המשתמשים בכלים האלה, ביצועי האפליקציות הם משחק אבוד לבני האדם ו זה צריך להיעשות על ידי כלים ותוכנה.

עם זה אני אעבור לחברים שלנו באי.די.איי.

אריק קוואנה: בסדר, ביל.

ביל אליס: תודה. משתף את המסך שלי כאן. אני מניח שמישהו יכול לאשר שאתה יכול לראות את המסך שלי?

ד"ר רובין בלור: כן.

אריק קוואנה: זה נראה בסדר.

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

דז בלנשפילד: אני אוהב את זה, אני הולך לזכור את זה.

אריק קוואנה: קילומטר טיפוסי לשעה.

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

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

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

על מנת לפתור זאת, על מנת לספק דרך טובה יותר, מה שהמדויק עושה הוא למעשה לקחת את עסקת מסלול משתמש הקצה, לוכד מטא נתונים אודותיו, לעקוב אחר העסקה דרך הרשת, לשרת האינטרנט, לתבנית ההיגיון העסקי אנו תומכים ב- .NET ו- ABAP וב- PeopleCode ו- E-Business Suite, ביישומים רב-שכביים שבסופו של דבר כל העסקאות עומדות לקיים אינטראקציה עם מערכת הרשומות. בין אם זה בדיקת מלאי, זמן הדיווח שעבד, הם תמיד מתקשרים עם מסד הנתונים. בסיס הנתונים הופך לבסיס לביצועים עסקיים. בסיס הנתונים מסתמך על אחסון. מה עונות המטא נתונים על העסקאות, מי, איזו עסקה, היכן בערימת היישומים ואז יש לנו ראות עמוקה ברמת הקוד כדי להראות לך מה מבצע. מידע זה נלכד ברציפות, מכניס למאגר ניהול הביצועים - ההופך לגיליון מוסיקה אחד עבור כולם כדי לראות מה קורה. ישנם אנשים וארגונים שונים שאכפת להם ממה שקורה: המומחים הטכניים, בעלי האפליקציות, בסופו של דבר מהעסק עצמו. כשיש בעיה, אתה רוצה לחלץ מידע על אותה עסקה.

לפני שנתבונן בעסקת ההשקעה, אני רוצה להראות לך איך זה יכול להראות לאנשים שונים בארגון. בשכבה לניהול, ייתכן שתרצה לקבל סקירה של מספר יישומים. אולי תרצה לדעת על הבריאות המחושבת על ידי תאימות והזמינות של SLA. הבריאות לא אומרת שהכל עובד במאה אחוז בצורה מושלמת. יש מקום במקרה זה שתוכל לראות כי עסקת ההשקעה נמצאת במצב אזהרה. עכשיו, קצת יותר עמוק, אולי בתחום העסקי, אתה רוצה לקבל פרטים נוספים על עסקאות בודדות, כאשר הם מפרים SLAs, ספירת עסקאות וכו '. צוות הפעולות ירצה לקבל הודעה על כך באמצעות התראה של כמה סוג. יש לנו התראות על ביצועים מובנים. אנו מודדים למעשה את הביצועים בדפדפן של משתמש הקצה. בין אם זה Internet Explorer, Chrome, Firefox וכו ', אנו מסוגלים לזהות, זה עונה על השאלה הראשונה: האם יש למשתמש קצה בעיה?

בואו נצלול פנימה ונראה מה עוד נוכל להראות בנושא. האנשים שמעוניינים בהופעה יפתחו את Precise. הם היו מעריכים את העסקאות. הם היו מסתכלים בעמודה SLA כדי לזהות עסקאות שאינן תואמות SLA. הם יוכלו לראות את משתמשי הקצה שהושפעו כמו גם את מה שעשתה אותה עסקה בזמן שזרם על פני היישום. הדרך בה אתה מפענח את ההירוגליפים האלה, זה הדפדפן, ה- URL, U הוא עבור URL, זו נקודת הכניסה ל- JVM. עכשיו ה- JVM הספציפי הזה גורם לשרת אינטרנט להתקשר ל- JVM השני שמבצע אז את הצהרת SQL. ברור שזו סוגיית מסד נתונים מכיוון שהצהרת SQL זו הייתה אחראית ל 72 אחוז מזמן התגובה. אנו ממוקדים בזמן. זמן הוא מטבע הביצועים. כך משתמשי קצה חווים אם הדברים מתנהלים לאט או לא, וזה מדד לצריכת משאבים. זה מאוד שימושי; זה סוג של מדד יחיד שהכי חשוב להערכת הביצועים. כאשר הבעיה מועברת ל- DBA, זו לא רק בעיית בסיס נתונים, אלא הצהרת SQL זו. זה ההקשר עליו דיברתי.

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

עכשיו למטה, הוא ניתוח זמן תגובה עבור הצהרת SQL. תשעים אחוז מזמן האחסון; עשרה אחוזים שימשו במעבד. אני יכול לראות את הטקסט של הצהרת SQL ואת דוח הממצאים. הטקסט של הצהרת SQL למעשה מתחיל לחשוף כמה בעיות קידוד. זהו כוכב נבחר; שמחזיר את כל השורות - סליחה, כל העמודות מהשורות שהוחזרו. אנו מחזירים עמודות נוספות שהיישום עשוי או לא עשוי להידרש לה. העמודות האלה צורכות מרחב ומשאבים לעיבוד. אם אתה מפעיל SAP, אחד השינויים הגדולים, מכיוון שמסד הנתונים של HANA הוא עמודי, זה בעצם שכתוב SAP כדי לא לבחור כוכב בחר כך שהם יכולים להפחית מאוד את צריכת המשאבים. זה בעצם משהו שקורה הרבה זמן גם ביישומים ביתיים, בין אם Java, .NET וכו '.

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

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

זה היה VMware. בוא ניכנס לקוד עצמו, קוד היישום. Precise תוכל להראות לך מה קורה ב- Java, .NET, קוד ABAP, E-Business, PeopleCode וכו '. אלו נקודות הכניסה לתוך, במקרה זה, ל- WebLogic. כאן למטה, יש דוח ממצאים שאומר לי שזה ה- EJBs שאתה צריך להסתכל עליהם ויגיד לי שקרתם גם נעילה במערכת הזו. שוב, התרגיל בתוך שכבת ההיגיון העסקי, כדי להראות מה קורה. במקרה זה, אני מסתכל על מקרים מסוימים; אני תומך גם באשכולות. אם פועלים מספר רב של JVMs, אתה יכול להסתכל על האשכול בכללותו, או להסתכל על צווארי בקבוק בתוך JVM הבודד.

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

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

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

אז שוב, תיעוד שיוכיח שההשקעה בחומרה הייתה שווה את זה והם העבירו כפי שציפה הספק הספציפי. יש הכל, בגלל המורכבות, מספר הדברים, יש כל מיני דברים שיכולים לקרות. במקרה זה, למעשה היה להם מצב שכולם האשימו את ה- DBA, ה- DBA היה כמו "טוב, לא כל כך מהר." כאן אנחנו בעצם מסתכלים על אפליקציית SAP, אני חושב שתרחיש מסוג זה הוא די נפוץ . מה שקרה היה שהם פיתחו עסקה בהתאמה אישית למשתמש. המשתמש הוא כמו, "זה כל כך איטי." מקודד ABAP - זו שפת התכנות ב- SAP - אמר, "זה סוגיית מסד נתונים." בסופו של דבר הם פותחים את Precise; הם מדדו את משתמש הקצה 60 שניות, כל כך טוב יותר מדקה. חמישים ושלוש שניות בילה בסוף האחורי. הם קידחו לקצה האחורי והם למעשה הצליחו לחשוף את הצהרת ה- SQL שהוצגה בסדר יורד.

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

אני מסתכל על הזמן, נראה שיש לנו עוד קצת זמן לעבור עוד כמה כאלה. אני זורם דרך אלה. יישום זה היה בפיתוח למעלה משנה. כשנכנסו ל QA, הם ראו ששרתי האינטרנט הוצאו ממאה אחוז ונראה שהאפליקציה לא יכולה לפעול תחת VMware. הדבר הראשון שכולם אמרו היה, "שימו את זה על פיזית; זה לא יכול לרוץ תחת VMware. "Precise למעשה הציעה להם דרכים נוספות לפתור את הבעיה. בדקנו את העסקאות, ראינו שיחת שרת אינטרנט, היא נכנסת כ- ASMX ב- IIS.NET. זה למעשה חשף את הקוד הבסיסי. אתה רואה את זה לאן אני מכוון? זה 23 יום, 11 שעות. וואו, איך זה אפשרי? ובכן כל הפקודה אורכת 9.4 שניות והדבר הזה מופעל 215, 000 פעמים. עבור כל הזמנה, הוא משתמש ב- 6 שניות של מעבד. זו הסיבה, הקוד הזה הוא הסיבה שהדבר הזה לעולם לא יכול היה לקנה מידה. לאמיתו של דבר, זה לא יכול היה לשנות את גודלו.

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

בסדר, אני בוחר ובוחר מבחינת דברים נוספים שאני יכול להראות לך. הרבה אנשים אוהבים את זה כי זה מצית חנויות רבות. אם אינך מצליח לפגוש SLA עסקי, וכולם כמו "עזרו לנו לצאת". בחנות זו היה מצב שה- SLA העסקי נמצא בהזמנות שהתקבלו עד השעה 15:00, הוא נשלח באותו יום. זה ממש חיוני שהם יוציאו את ההזמנות, והמחסן עמוס מאוד. מסך הזמנת המכירות של JD Edwards זה היה קופא, ותוכלו לקבל רעיון טוב מאוד שמדובר במערכת ניהול מלאי בזמן אמת. מדפים ריקים אינם מקובלים בקמעונאות. צריך שיהיה שם את הסחורה כדי למכור אותו. מה שעשינו זה שצללנו, במקרה זה, אנו מסתכלים על בסיס נתונים של שרת SQL. המראה והתחושה זהים בין אם זה SQL, Oracle, DB2 או Sybase.

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

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

אריק קוואנה: כן, לכי על זה.

ביל אליס: אוקיי, אני אדלג קדימה. דבר אחד אני רוצה שתשימו לב, דיברנו על חומרה, דיברנו על SAP, דיברנו על .NET, דיברנו על JD Edwards וסביבת Java-SQL Server. זה SAP, כאן אנחנו מסתכלים על PeopleSoft. מטריקס התמיכה של Precise הוא רחב ועמוק. אם יש לך אפליקציה, סביר להניח, נוכל להתאים אותה בכדי לספק רמה זו של הנראות. אחד השינויים הגדולים שקורה ברגע זה הוא הניידות. PeopleSoft הציגה ניידות באמצעות ממשק המשתמש הנוזלי שלה. ממשק המשתמש של הנוזלים משתמש במערכת בצורה שונה מאוד. יישום זה מתפתח. ממשק המשתמש של נוזלים - מה שהוא עושה מבחינה ניהולית הוא שהוא מאפשר למשתמשים הקצה להשתמש בטלפון שלהם וזה מגדיל מאוד את הפרודוקטיביות. אם יש לך מאות או אלפים או אפילו יותר עובדים, אם אתה יכול להגדיל את הפרודוקטיביות שלהם, 1-2 אחוז, אתה יכול להשפיע מאוד על שכר השכר ועל כל השאר. מה שקרה היה, שהחנות הספציפית הזו גללה את ממשק ה- PeopleSoft Fluid UI. עכשיו, כשמדברים על מורכבות, מדובר בערימה של PeopleSoft. יישום אחד, מינימום שש טכנולוגיות, מספר משתמשי קצה. איך מתחילים את זה?

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

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

עכשיו מה שזה אומר לך הוא שממשק המשתמש של הנוזלים משתמש לפחות במספרים של 10x של חיבורים במקביל. אנו מתחילים לסגת את הנעשה תחת הכיסויים באמצעות PeopleSoft, כך שתוכלו לראות את ההשפעה על שרתי האינטרנט, את העובדה ש- SLA מתחילים להפר. לא מתכוון להיכנס לכל דבר, אבל מה שבסופו של דבר קורה הוא שהם בעצם מסתמכים על העברת הודעות. בעיקרון הם מתעמלים הוא WebLogic וגורם לתור בתוך טוקסידו. היה למעשה סוגיית תלות רב-שכבתית שהופיעה עם ממשק המשתמש של הנוזלים, אך Precise הצליחה להראות שעל ידי חבורה שלמה של דברים שונים, שנוכל להתמקד במה הבעיה. מסתבר שהייתה גם בעיה בבסיס הנתונים עצמו. יש למעשה קובץ יומן העברת הודעות, ובגלל כל המשתמשים בו זמנית, קובץ היומן הזה ננעל. בעיקרון היו לו דברים לכוון, בכל נדבך בערימת היישומים. דברו על מורכבות, הנה למעשה שכבת הטוקסידו מראה לכם את התור ותוכלו לראות את הביצועים משפילים גם הם ברובד זה. יכולתי לראות את התהליכים; יכולתי לראות את הדומיינים ואת השרתים. בטוקסידו, כדי שאנשים יוכלו להשתמש בזה, בדרך כלל מה שאתה עושה זה לפתוח תורים, דומיינים ושרתים נוספים, ממש כמו בסופרמרקט כדי להקל על הגודש, כדי למזער את זמן התור. האפשרות האחרונה והאחרונה, Precise מציגה מידע רב.

כפי שציינתי קודם, כל עסקה משמעותית מקיימת אינטראקציה עם מערכת הרשומות. הראות למאגר היא בעלת חשיבות עליונה. מדויק מראה מה קורה בבסיס הנתונים, בתוך WebLogic, בתוך Java, .NET, בתוך הדפדפן, אך המקום ש- Precise באמת מצטיין נמצא ברובד הנתונים. זו במקרה חולשת המתחרים שלנו. הרשה לי להראות לך אחת הדרכים ש- Precise יכול לעזור לך לעבור את זה. אני לא מתכוון לבזבז זמן על משולש אופטימיזציית בסיס הנתונים, אך בעיקרון אנו בוחנים שינויים בסוג נמוך, בסיכון נמוך, בהיקף נרחב, בסיכון גבוה ובעלות גבוהה. אני למעשה אעדכן את השקופית לאחר מכן אם אנשים רוצים לנסות להסתכל עליה. זה מדריך די גדול, אני חושב, לבעיות כוונון. להלן התצוגה המקדימה של Precise for Oracle. לראש הדו"ח הממצאים, ההשפעה של 60 אחוז היא הצהרת SQL ספציפית זו. אם אתה פותח את מסך הפעילות הזה, הוא מראה אותו שם למעלה. אני יכול להסתכל על ההצהרה הנבחרת הזו, יש תוכנית ביצוע אחת. כל ביצוע לוקח שנייה - 48, 000 הוצאות להורג. זה מוסיף 48, 000 שעות נוספות של הוצאות להורג.

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

ואז, ממדידה לפני ואחרי, אתה מסתכל על זמן ביצוע של שנייה אחת, מצטבר עד 9 שעות 54 דקות, עם אותה הצהרת SQL מדויקת, אך לאחר שהאינדקס הזה מובנה באותיות גדולות ל 58, 000 הוצאות להורג, התגובה הזמן יורד לתת אלפיות השנייה, מצטברים יחד, זה מגיע לשבע שניות. בעצם חסכתי עשר שעות של מעבד בשרת שלי. זה ענק. מכיוון שאם אני לא אמור לרענן שרת, אוכל לחיות בשרת זה. אני בעצם מצמצמת את השימוש בשרת הזה ב 20 אחוז ותוכלו למעשה לראות את הקודם והאחריו. זה סוג הנראות ש- Precise יכולה לספק. יש גם כמה דברים נוספים שאנחנו עשויים להסתכל עליהם, מדוע יש לך את כל המדדים האלה אם לא משתמשים בהם? הם יכולים לעקוב עם זה. יש אדריכלות, ואני אעטוף אותה מכיוון שאנו מגיעים לראש השעה. אני מאמין אמיתי בפתרון זה ואנחנו רוצים שתהיה מאמין אמיתי. ב- IDERA אנו מאמינים כי ניסוי הופך את הלקוח, כך שאם אתה מעוניין, אנו יכולים לבצע הערכות באתר שלך.

עם זה אני אחזיר את המשואה.

אריק קוואנה: כן, זה היה פרט אדיר שהראית שם. זה באמת די מרתק. אני חושב שהזכרתי לך בעבר את זה - ואני יודע בכמה משידורי האינטרנט האחרים שעשינו עם IDERA, הזכרתי את זה - אני למעשה מעקב אחר מדויק עוד לפני שנרכש על ידי IDERA, כל הדרך חזרה לשנת 2008, אני חושב, או לשנת 2009. הייתי מוקסם מזה. אני סקרן לדעת כמה עבודה עוברת להישאר מעל המהדורות החדשות של יישומים. הזכרת את SAP HANA שלדעתי היה די מרשים שאפשר למעשה לחפור בארכיטקטורת HANA ולעשות שם פיתרון בעיות. כמה אנשים יש לך? כמה מאמץ הוא מצידך וכמה מזה ניתן לעשות דינמיות במידה מסוימת, כלומר כאשר הכלי מתפרס, אתה מתחיל לזחול ולראות דברים שונים? כמה מזה יכול להיות כלי דינאמי, מיון, ולהתברר בו, כך שתוכל לעזור לאנשים לפתור סביבות מורכבות?

ביל אליס: שאלת שם הרבה שאלות.

אריק קוואנה: אני יודע, סליחה.

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

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

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

משתתף אחד שואל, כמה קשה ליישם את מדויק? אדם אחר שאל, מי האנשים - ברור ש- DBA- אבל מי הם כמה תפקידים אחרים בארגון שישתמשו בכלי הזה?

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

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

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

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

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

ובכן חברים, נעבור לארכיון שידור רשת זה. תוכלו לקפוץ באופן מקוון ל- Techopedia או insideanalysis.com ואו, תודה על זמנכם, אנו נתעדכן בפעם הבאה. תשמור, ביי ביי.