בדיקות העמסה של SharePoint באירוע SharePoint Experts 2014

מאי 25, 2014

תגיות: ,
2 תגובות

מצ”ב מצגת שהעברתי באירוע SharePoint Experts 2014 בנושא ביצועים. חלק זה במצגת מטרתו לספק תכנית-על של מבדקי העמסה ודרכי התמודדות לבחינת עמידות תשתית ה SharePoint, המערכות התומכות (מסדי נתונים, Active Directory, רכיבי תקשורת וכדו') ופיתוחים שנעשו במהלך הקמת הפורטל או אתר האינטרנט מבוסס תשתית פרסום של ShsarePoint. בדיקת העמסה מתמקדת בהדמיה של גלישת מבקרים אנונימיים או מזוהים בדפי תוכן של פורטל ארגוני או אתר אינטרנט.

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

תהליך הבדיקה

מתודולוגיית הבדיקה

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

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

סביבת הבדיקות

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

מערכות תומכות ומשיקות

חובה לוודא שהמערכות התומכות מסוגלות להתמודד עם העומס שייווצר במהלך הבדיקה. לדוגמה יש לוודא שישנם מספר Domain Controllers ושרתי ה-DNS כדי לתמוך בעומס הצפוי. עומס רכיבים אלו עלול לשבש את תוכנת הבדיקה ובמקרים מסוימים לפגוע בחוויית המשתמש של מערכות שבייצור, גם אם העמסה התבצעה על סביבת בדיקות או קדם ייצור!!!

מערכת הערות
תקשורת חיצונית

שליטה ובקרה על קווי התקשורת למניעת קריסה

שרתי Firewall שליטה ובקרה על התקפות DOS. לפעמים ה Firewall עלול לזהות את בדיקת העמסה כהתקפה
Load Balancer חלוקה נכונה ועמידות בעומסים
תקשורת פנימית SharePoint תקשורת בין השרתים הקדמיים ואחוריים ורכיבי תקשורת נוספים
Active directory בפרט בהעמסה של משתמשים מזוהים
וירטואליזציה חוות השרתים של SharePoint מותקנת על גבי התשתית הווירטואלית הארגונית, יש לוודא שלא תהיה פגיעה במערכות אחרות שמתארחות באותה הסביבה
מסדי נתונים שרתי מסדי הנתונים ייעודיים עבור ה SharePoint או מסדי נתונים משותפים
אחסון (Storage) מידת ניצולת של IOPS יכולה להשפיע על מערכות אחרות
ניטור ובקרה השפעה על תהליכי ניטור ובקרה בזמן הבדיקה. האם לנטרל בזמן בזמן הבדיקה? או שכדאי לודא את פעילות הניטור באותה הזדמנות
מערכות נוספות בארגון… בדיקה שהמערוכת נוספות יכולות להתמודד עם העומס. לדוגמה: קריאות ל Web Services, מסדי נתונים אפליקטיביים וכדו’

פרמטרים כללים של הבדיקה

פרמטר ערך
תשתית SharePoint 2013
פורטל סוג הפרוטל ארגוני/אתר אינטרנט
משתמש אנונימי/מזוהה מזוהים בפרוטוקול Kerberos
מספר משתמשים בו זמנית 150
זמן חשיבה בין פעולות משתמש 3 שניות
טעינה של משאבי דף (תמונות, CSS, JS) כן (טעינת התמונות תתבצע בפעם ראשונה עבור כל משתמש, עבור כל תסריט)
זמן חימום מנועים לפני הבדיקה 3 דקות
זמן ריצה מתוכנן שלוש שעות ברוטו (כל סבב שעה)
סוג ריצה (מדורג, קבוע, יעד לביצועים) מדורג (10 משתמשים כל 20 שניות)
פרוטוקול HTTPS פעיל לא
מנגנון Output Cache פעיל כן (למשך שעה)
מספר תחנות בדיקה 4

מדדי הצלחה

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

מדד ערך הערות
זמן תגובה עד 2 שניות של 90 אחוז מהתגובות דפים שזמן הטעינה שלהם לקח יותר מ 2 שניות נחשב לשגיאה/תקלה
HTTP Response 200, 301, 302 כל הודעות 400 ומעלה נחשבות לשגיאת מערכת
מחרוזת מופיעה בתחתית הדף מפת אתר אם המילה מפת אתר אינה מופיע בכל אחד מהדפים, הבדיקה נכשלה

צפי לעומסים ונפחים במהלך הבדיקה

מספר כתובת IP של תחנות הבדיקה 10
ניצולת CPU בשרתים עד 100%
ניצולת זיכרון בשרתים עד 75%
צפי לנפח תעבורה במהלך הבדיקה 4.5GB
צפי ל Page per second 50
צפי ל Request per second 300 (לאחר הפעלת Output Cache)
צפי לזמן טעינה ממוצע של דף 1.6 שניות

סיכונים וגורמים לעצירת תהליך העמסה

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

מערכת סף העמסה אחראי דווח
Web Application Firewall 90% עומס קשורת
firewall 80% עומס תקשורת
קווי תקשורת 70% ניצולת של הקווים תקשורת
מסדי נתונים 90% ניצולות DBA
וירטואליזצייה   תשתיות

הכנה לבדיקות ביצועים

נתונים לבדיקה

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

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

הכנת התשתית של צוות הפיתוח

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

  • הגדרה ב Web.Config ל Debug mode=false
  • הפעלה (לפי הצורך) ובדיקה של מצב ה Output Cache
  • הפעלה Cache לקבצי משאבים (תמונות, קבצי JS ו CSS) ברמת ה Reverse Proxy עם TTL בזמן סביר
  • הפעלה של AppFabric Cache ובדיקה שעובד מול הזיכרון ולא מול השירות
  • בדיקה שאין קבצים חסרים – ניתן לבצע זאת באמצעות HTTP Watch
  • להעלות את רמת ה Severity של הלוג Unexpected
  • לבדוק שהאתר נמצא במצב אנונימי או מזוהה (לפי סוג האתר)
  • ביטול של ה Developer Dashboard
  • לבצע בדיקה שאין הגדרות IP סותרות בקובץ ה HOST ממה שמוגדר ב DNS (אחרת הבדיקות יכולות להיעשות מול שרת בודד ולא מול מאזן העומסים).

הכנה של צוות התשתיות

  • הפעלה של Blob Cache
  • הפעלת ניטור
  • Perfmon לפי ה PLA
  • פעלת לוגים של IIS
  • SharePoint (ULS)
  • מניעת/הפעלת התמודדות עם התקפות DOS ב Firewall

במהלך הבדיקה

איסוף נתונים בדיקות במהלך הבדיקה

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

נתונים שיש לאסוף לצרכי סטטיסטיקה, ניתוח והערכה:

  • דגימת counters מכל השרתים בחווה, כולל את שרתי מסד הנתונים – על פיPerformance Analysis of Logs (PAL) – ראה נספח א'
  • בחינה של קבצי הלוג של IIS, כולל: מספר פניות לשרת ה IIS עבור דפי ASPX, קבצי JS, CSS ותמונות
  • לבדוק התפלגות פניות בין השרתים הקדמיים
  • נתונים מתוכנת העמסה:
    • ממוצע זמני טעינה של דף, אחוזון 90 ו 95
    • מספר פניות לדף בשנייה (דפים בלבד)
    • מספר בקשות בשנייה (דפים ומשאבים נלווים)
    • מספר פניות כולל של דפים
    • מספר שגיאות בתהליך הריצה
  • בדפים מסוימים יש לבדוק האם הדף החזיר תוצאות כמצופה. לדוגמה האם מופיע בדף ערך כלשהו (לא יבוצע בשלב זה)
  • מצב המשאבים בתחנות הבדיקה – עומס בעמדות הבדיקה כדוגמת רשת, זיכרון או CPU יכול להשפיע לרעה על תוצאות הבדיקה

פעולות לביצוע במהלך הבדיקה

במהלך בדיקה יש לבצע את הפעולות הבאות:

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

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

איסוף מדדים מהשרתים וניתוח

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

במקרה שמתגלית בעיה בדפים (אחד או יותר) ניתן לבודד בעיה לפי דפוס הפעולה הבא:

  • במידה וכל הדפים מספקים זמני תגובה גרועים, לבדוק האם האיטיות נובעת מרכיב שממוקם ב Master Page
  • להריץ בדיקת העמסה על דף בודד בו מתרחשת התקלה או על דף בודד מתוך כלל הדפים האיטיים (ולא על כל הסט)
  • להריץ עליה מדורגת של 10-20 משתמשים בכל שלב, עד לזיהוי נקודת השבירה, לעבור לריצה עם מספר משתמשים קבוע
  • לנסות להוריד מתסריט הבדיקות טעינה של Sub Request (משאבים נלווים כדוגמת תמונות, קבצי CSS או JS)
  • להחליף את ה Master Page לזה של SharePoint OOTB ולמותאם אישית ולהשוות בין התוצאות

מדידת ביצועים והוספת הודעות דרך Trace

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

  • כדי למדוד את הזמן שלקטע הקוד שאנו מתכוונים לעקוב אחר – יש להשתמש במחלקה SPMonitoredScope
  • על מנת להוסיף הודעות יומן ואזהרות – יש להשתמש בפקודה SPCriticalTraceCounter.AddDataToScope

מידע זה יהיה זמין בלוח המחוונים של ה Developer Dashboard

מרכיבים ואפיינים שעשויים להשפיע על תהליך הבדיקה

  • גלישה ב SSL לעומת HTTP סטנדרטי. הערה: ההמלצה להפעיל את ה HTTPS בתצורת Off Load בשרתי ה Reverse Proxy ולא בשרתי ה SharePoint
  • רמת הדחיסה של קבצים סטטיים/דינמיים ב SharePoint ובשרתי ה Reverse Proxy. הערה: לבדוק שאין הגדרת דחיסה כפולה

הפעלת Output Cache בדפי SharePoint

זיכרון מטמון פלט של דף – "Output Cache" היא אחת הטכניקות המומלצות לשיפור ביצועי יישומי אינטרנט. טכניקה זו מספקת זמני תגובה מהירים יותר, והפחתת עומסים על שרתי האינטרנט, בסיסי הנתונים והאפליקציה. לשיפור ביצועים מומלץ מאוד להפעיל תכונה זו, למידע נוסף: Configure cache settings for a web application in SharePoint Server 2013.

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

 

Yoel
בהצלחה,
יואל הורביץ
יועץ בכיר בקבוצת היועצים (MCS),  מיקרוסופט ישראל


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

כתיבת תגובה

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

2 תגובות

  1. ברק אליהומאי 25, 2014 ב 12:44

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

    הגב
    1. קהילת ה- SharePoint של מיקרוסופטיוני 10, 2014 ב 11:19

      הי אליהו,

      ראשית תודה!
      אנו עומדים לעדכן את הבלוג עם עמוד "תוכן האתר" שיכיל את כל המאמרים שפורסמו.

      יואל

      הגב