מהי בדיקת עומסים (Load Testing)?

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

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

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

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

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

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

סוגי בדיקות ביצועים: Load, Stress, Spike ו־Soak

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

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

למידע נוסף על בדיקות ביצועים בסביבות רשת, אפשר לעיין גם במדריך בדיקות עומסים לרשתות – מדריך מעשי.

מדדי ביצועים שחייבים להכיר

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

1. Response Time – זמן תגובה

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

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

מומלץ למדוד אחוזונים ולא להסתפק בממוצע:

• p50: זמן התגובה שחצי מהבקשות מסיימות בתוך פרק זמן זה.
• p90: זמן התגובה שמתחתיו מסתיימות 90% מהבקשות.
• p95: זמן התגובה שמתחתיו מסתיימות 95% מהבקשות.
• p99: זמן התגובה שמתחתיו מסתיימות 99% מהבקשות.

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

2. Throughput – תפוקה

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

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

3. Error Rate – שיעור שגיאות

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

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

4. Resource Utilization – ניצול משאבים

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

• CPU – ניצול המעבד וזמן ההמתנה לעיבוד.
• Memory – שימוש בזיכרון, לחץ על הזיכרון ופעילות Garbage Collection במערכות רלוונטיות.
• Disk I/O – זמני קריאה וכתיבה לדיסק ותורים.
• Network – רוחב פס, השהיה, שגיאות ואובדן מנות לפי הצורך.
• Database – מספר חיבורים פעילים, זמני שאילתות, נעילות ותורים.
• Application – תורים פנימיים, מספר Threads, Pool saturation וחריגות.

5. Concurrent Users – משתמשים בו־זמנית

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

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

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

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

שלב 1: הגדרת מטרת הבדיקה

נסחו שאלה ברורה שהבדיקה אמורה לענות עליה. לדוגמה:

• האם מערכת ההזמנות יכולה לתמוך ב־500 משתמשים פעילים בו־זמנית?
• האם 95% מבקשות החיפוש מסתיימות בתוך שנייה אחת?
• האם שירות ה־API מסוגל להשלים 200 בקשות לשנייה עם שיעור שגיאות נמוך מ־1%?
• האם המערכת נשארת יציבה תחת עומס במשך ארבע שעות?

יש להתאים את היעדים למאפייני המערכת ולהסכמי השירות שלה. אין סף יחיד שמתאים לכל אתר או שירות.

שלב 2: בחירת תרחישי שימוש

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

1. כניסה לעמוד הבית.
2. חיפוש מוצר או פתיחת קטגוריה.
3. צפייה בפרטי מוצר.
4. הוספת מוצר לסל.
5. מעבר לתהליך התשלום בסביבת בדיקה.

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

שלב 3: הערכת דפוסי התנועה

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

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

שלב 4: הגדרת קריטריוני הצלחה

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

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

שלב 5: הכנת סביבת הבדיקה

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

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

כלים לביצוע Load Testing

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

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

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

דוגמה מעשית: איך מבצעים בדיקת עומסים עם Apache JMeter?

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

שלב 1: יצירת Test Plan

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

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

שלב 2: הגדרת בקשת HTTP

הוסיפו HTTP Request עם כתובת השירות, שיטת הבקשה והפרמטרים הנדרשים. לדוגמה, בקשת GET לנקודת קצה ייעודית של חיפוש בסביבת הבדיקות.

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

שלב 3: הוספת בדיקות תקינות

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

שלב 4: הרצת הבדיקה

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

שלב 5: ניתוח התוצאות

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

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

דוגמה מעשית: בדיקת עומסים עם k6

k6 מאפשר לכתוב תרחישי עומס ב־JavaScript ולהגדיר ספי ביצועים. בדוגמה הבאה נבדוק נקודת קצה של API בסביבת בדיקות מורשית.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 20,
  duration: '1m',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const response = http.get(
    'https://test.example.com/api/products'
  );

  check(response, {
    'status is 200': (r) => r.status === 200,
  });

  sleep(1);
}

הקוד מדגים הרצה של 20 משתמשים וירטואליים למשך דקה. כל משתמש שולח בקשות לנקודת הקצה, ממתין שנייה בין איטרציות ובודק אם התקבלה תשובת HTTP 200.

הספים שהוגדרו דורשים ששיעור הבקשות שנכשלו יהיה נמוך מ־1% ושאחוזון p95 של משך בקשות HTTP יהיה נמוך מ־500 מילישניות.

הכתובת https://test.example.com/api/products היא כתובת דוגמה בלבד. יש להחליף אותה בנקודת קצה קיימת ומורשית בסביבת הבדיקה שלכם.

איך מריצים את הבדיקה?

שמרו את התסריט בקובץ בשם load-test.js והפעילו אותו באמצעות k6:

k6 run load-test.js

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

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

בדיקות עומסים ל־API ולמסדי נתונים

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

מה בודקים ב־API?

• זמן תגובה של כל נקודת קצה חשובה.
• תפוקה תחת עומס מתמשך.
• קודי HTTP ושיעור שגיאות.
• התנהגות במצבי Timeout ו־Rate Limiting.
• השפעת מנגנוני אימות והרשאות.
• השפעת גודל הבקשה והתשובה.
• התנהגות בעת תלות בשירותים אחרים.

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

מה בודקים במסד הנתונים?

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

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

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

איך מנתחים את תוצאות בדיקת העומסים?

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

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

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

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

שאלות שצריך לשאול בעת ניתוח התוצאות

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

זיהוי צווארי בקבוק ופתרון בעיות ביצועים

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

עומס גבוה על המעבד

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

מחסור בזיכרון

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

שאילתות איטיות במסד הנתונים

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

תורים וחיבורים מוגבלים

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

מטמון לא יעיל

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

מה עושים לאחר זיהוי הבעיה?

1. תעדו את התנאים שבהם הבעיה הופיעה.
2. זהו את הרכיב החשוד בעזרת מדדים ולוגים.
3. שנו גורם אחד בכל פעם, ככל האפשר.
4. הריצו שוב את אותו תרחיש בתנאים דומים.
5. השוו את המדדים לפני ואחרי השינוי.
6. בדקו שלא נוצרה רגרסיה ברכיבים אחרים.

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

טעויות נפוצות בבדיקות עומסים

צ'קליסט לביצוע בדיקת עומסים

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

שאלות נפוצות על בדיקות עומסים

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

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

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

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