מערכת שעובדת מצוין עם משתמש אחד יכולה לקרוס לחלוטין עם אלף. בדיקות עומסים (Load Testing) הן הדרך היחידה לדעת מראש איפה נמצא הקיר — לפני שהלקוחות מגלים אותו בשבילכם, בדרך כלל ביום ההשקה או בקמפיין הגדול של השנה.
מה זה בדיקות עומסים ובמה הן שונות מבדיקות ביצועים
- Load Testing — הרצת עומס צפוי ומציאותי כדי לוודא שהמערכת עומדת ביעדי הביצועים.
- Stress Testing — הגדלת העומס עד לנקודת השבירה, כדי לדעת מה הגבול ואיך המערכת נשברת.
- Spike Testing — קפיצה חדה ופתאומית בתעבורה (פרסום בטלוויזיה, מבצע בזק).
- Soak Testing — עומס בינוני לאורך שעות או ימים, כדי לחשוף דליפות זיכרון והידרדרות הדרגתית.
- Scalability Testing — בדיקה שהמערכת באמת מתרחבת כשמוסיפים לה משאבים.
רוב הצוותים מריצים רק את הראשון. הבעיה האמיתית מתגלה דווקא בשלושה האחרונים.
איך מגדירים יעדי ביצועים לפני שמתחילים
בלי יעדים מספריים, כל תוצאה נראית "בסדר". לפני הרצה ראשונה, הגדירו:
- מספר משתמשים במקביל — לא "הרבה", אלא מספר שנגזר מנתוני אנליטיקס אמיתיים.
- זמן תגובה מקסימלי — עבדו לפי אחוזונים ולא לפי ממוצע: P95 ו-P99, לא Average.
- שיעור שגיאות מותר — לרוב מתחת ל-1%.
- תפוקה (Throughput) — כמה בקשות לשנייה המערכת חייבת לספוג.
- צריכת משאבים — CPU, זיכרון, חיבורי DB ומספר ה-threads בשיא.
למה הממוצע משקר
אם 95 בקשות חוזרות ב-100ms וחמש בקשות חוזרות ב-10 שניות, הממוצע הוא כ-600ms — נראה מצוין. אבל 5% מהמשתמשים שלכם חוו אתר תקוע. תמיד תמדדו P95 ו-P99, ותסתכלו גם על הפיזור, לא רק על המספר המרכזי.
תרחיש עומס שמשקף מציאות
הטעות הנפוצה ביותר: להפציץ endpoint אחד באלפי בקשות ולקרוא לזה בדיקת עומסים. משתמש אמיתי מתחבר, מחפש, גולל, מוסיף לעגלה, ממתין, ומשלם. תרחיש טוב כולל:
- Think time — השהיות אנושיות בין פעולות.
- Ramp-up הדרגתי — עלייה מדורגת ולא זינוק מיידי, כדי לזהות את נקודת הפיתול.
- נתונים מגוונים — משתמשים שונים, מוצרים שונים, כדי לא לעבוד בטעות רק מול הקאש.
- תמהיל פעולות — 80% קריאות, 20% כתיבות, לפי ההתנהגות האמיתית במערכת.
סקריפט Python ייעודי מול כלי מדף
כלים מסחריים לבדיקות עומסים דורשים רישוי יקר ולעיתים גם נעילה לספק. עבור רוב המערכות, סקריפט Python ייעודי (Locust, asyncio, Playwright) נותן תוצאה טובה יותר:
- שליטה מלאה בלוגיקה — אימות מורכב, חתימות, זרימות רב-שלביות.
- אינטגרציה טבעית ל-CI/CD בלי שרתי רישוי.
- עלות אפס על כלים, והקוד נשאר בבעלותכם.
- אפשרות להרחיב סקריפטים קיימים של JMeter או k6 במקום לזרוק אותם.
מה בודקים אחרי ההרצה
התוצאה החשובה היא לא הגרף — אלא צוואר הבקבוק. חפשו:
- שאילתות DB איטיות ובעיות N+1
- מיצוי Connection Pool
- העדר אינדקסים
- קריאות סינכרוניות לשירותים חיצוניים
- דליפות זיכרון שמופיעות רק אחרי שעה של עומס
סיכום
בדיקות עומסים אינן פרויקט חד-פעמי לפני עלייה לאוויר, אלא חלק קבוע מהתהליך. הגדירו יעדים מספריים, בנו תרחישים שמשקפים משתמשים אמיתיים, מדדו באחוזונים, והריצו באופן שוטף ב-CI.
רוצים לראות איך זה נראה בפועל על המערכת שלכם? כל הפרטים בעמוד [בדיקות עומסים](/load-testing), או פשוט [צרו קשר](/contact).