שאלה איך אתה עושה בדיקות עומס ותכנון קיבולת עבור אתרי אינטרנט?


זה שאלה קנונית על תכנון קיבולת עבור אתרי אינטרנט.

Related:

מה הם כמה כלים מומלצים ושיטות של תכנון קיבולת עבור אתרי אינטרנט ויישומי אינטרנט?

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


111
2018-01-16 22:49






תשובות:


התשובה הקצרה היא: אף אחד לא יכול לענות על השאלה הזאת חוץ ממך.

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

אתר סטטי פשוט של עמוד אחד יכול להתארח ב- Pentium Pro 150 ועדיין לשרת אלפי הופעות מדי יום.

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

סקירה קצרה של זה היא:

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

שים את התסריט שלך במקום

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

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

אז, אני הולך להקים באמצע מכונה וירטואלית מופעל (שתי ליבות, 512 MB זיכרון RAM, 4 GB HDD) ולהתקין את איזון עומס האהוב עלי, haproxy בפנים רד האט לינוקס על VM.

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

הוסף ניטור

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

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

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

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

  • השימוש ב- CPU
  • שימוש ב- RAM
  • שימוש בדיסק
  • חביון הדיסק
  • ניצול רשת

אתה יכול גם לבחור להסתכל על deadlocks SQL, לחפש פעמים, וכו 'בהתאם למה שאתה בודק במיוחד.

הוסף תנועה

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

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

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

לחץ על הקסם ללכת כפתור ולצפות שרתי האינטרנט שלך להמיס לקרוס.

להעריך את התוצאות

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

בצע תיקון

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

כדי להגדיל את קנה המידה, לקבל שרתי אינטרנט גדולים יותר, RAM יותר, דיסקים מהירים יותר.

כדי להגדילה, קבל עוד שרתים.

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

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

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

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

לשטוף, לחזור

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

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


119
2018-04-29 14:05



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


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

מדידת הביצועים נעשית תמיד עם זמן יחידות, כמו

  • הם מה אכפת למשתמשים
  • הם יכולים להיות scaled מעלה ומטה

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


9
2018-04-21 22:32





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

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

בלי לחץ...

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

למרבה המזל, יש ספר כזה:אמנות תכנון קיבולת"


8





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

הגדרת Apache עם Mod_Prefork

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

אתה צריך לעולם לא השתמש ב- out-the-box Apache config. אתה תמיד צריך לכוון את אפאצ 'י לאתר שלך. הראשי תצורת אפאצ 'י קובץ ב CentOS ממוקם ב /etc/httpd/conf/httpd.conf, וקובץ ההגדרות הראשי של אפאצ 'י על מערכות אובונטו נמצא בדרך כלל ב /etc/apache2/apache2.conf. קבצי תצורה נוספים משמשים לדברים כמו מארחים וירטואליים.

כמו הרבה תוכנות, אפאצ 'י בנוי להיות גמיש ומותאם אישית על פי הצרכים של האתר הספציפי. ישנם מודולים Multi-Processing שונים כי Apache יכול להיות מוגדר להשתמש כדי לקשור ליציאת רשת ולקבל ולעבד את הבקשות.

רוב הזמן על התקנות Apache ברירת המחדל שמגיעים עם שרתי CentOS ו- Ubuntu, MPM "mod_prefork"בהנחה שאתה משתמש ב- mod_prefork (אם אתה לא בטוח, אז זה סביר יותר, אבל רק אתה יכול לקבוע את זה) הנה את היסודות של איך להגדיר את זה:

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

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


5



השימוש בזיכרון מבוסס על הדף בלבד פגום מעט, אנא בדוק f.e. stackoverflow.com/questions/7880784/... בנוסף, ייתכן שתרצה להשתמש בסקריפט python "ps_mem.py" במקום בראש הדף לשימוש בזיכרון, או אפילו להשתמש בערכים הנלווים לתהליך תחת proc - Dennis Nolte
התשובה כולה שווה בגלל ההערה שהוספת: "לעולם אל תשתמש בתצורת Apache מחוץ לקופסה". לעולם לא נוכל להדגיש זאת. - ezra-s


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


0