הגדרת בדיקות עומס לתשתית באמצעות wrk/wrk2

בדיקות עומס: היכן התשתית נשברת ראשונה

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

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

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

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

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

אפקט מדיד: שיעור הכשלים, מרווח קיבולת, זמן התאוששות

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

כל נקודה נמדדת לפני ואחרי השינויים על אותו פרופיל בדיוק — אחרת להשוואה אין כל הוכחה.

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

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

פורמטים של בדיקות עומס: מצבים, סביבות בדיקה, מגבלות

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

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

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

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

שלבי העבודה: מביקורת המערכת ועד מסירת התקנונים

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

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

1. ביקורת המערכת. משרטטים את מפת הקשרים, מגבלות החיבורים, מקומות אחסון המצב; מפרידים בין צמתים למדידות מבודדות לאלה שנבדקים רק יחד.
2. תרחישי עומס. מתאמים פרופילים: עומס יציב, גידול מדורג עד כשל, שיאים קצרים. מתעדים עצימות יעד והשהיה מותרת ב-p95 וב-p99.
3. הכנת נתוני בדיקה. ממלאים את הסביבה בנפח רשומות ובהתפלגות מפתחות דומים — אחרת המטמון והאינדקסים מתנהגים אחרת מאשר על נתונים אמיתיים.
4. הרכבת הסביבה וכיול המחולל. בודקים שכלי העומס אינו נתקע במשאבים משלו, ומוסיפים חימום לפני המדידות.
5. ריצות ותצפית. אוספים מטריקות של היישום והמארחים בו-זמנית ומשנים משתנה אחד בכל פעם — כך צוואר הבקבוק מזוהה באופן חד-משמעי.
6. אימות התוצאה. חוזרים על הפרופיל ומשווים את הפיזור בין ריצות: שחזוריות חשובה יותר מערך בודד ויפה.
7. מסירת התקנון. מוסרים תרחישים, קונפיגורציות, לוחות בקרה ונוהל בדיקות חוזרות לאחר שינויים במערכת.

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

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

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

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

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

מקרה בוחן: כיצד הסרנו הידרדרות תחת עומס שיא

שירות עם אי-אחידות תעבורה יומית: בשיא הערב שיעור השגיאות הגיע ל-6–7%, וזמן התגובה גדל פי כמה מרמת העבודה. התקלות לא היו קבועות — המערכת החזיקה בזכות המטמון ומרווח הכוח, ולכן התורן נודע על ההידרדרות מפניות לתמיכה, ולא מהתראות.

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

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

מה לעשות אם המערכת עובדת ואסור להפיל אותה

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

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

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

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

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

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

ספקות טכניים: בידוד, נתונים, מהימנות המדידות

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

מהיכן מגיעים נתוני הבדיקה ומידע אישי?

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

עד כמה מהימנות המדידות והאם התוצאה משוחזרת?

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

מה נדרש מכם להתחלה וכיצד נחזור עם הערכה

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

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

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