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

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

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

בדיקות עומסים חושפות צווארי בקבוק: מסד נתונים, CPU, זיכרון, רשת. הפלט הוא מספרים קונקרטיים: אחזור p95, שיעור שגיאות, RPS מקסימלי. זה מונע השבתות ויכול לחסוך עד 40% מתקציב התשתית. בהתבסס על הניסיון שלנו (מעל 100 פרויקטים), לקוחות קיצצו בעלויות השרתים ב-30–50% לאחר אופטימיזציה מתוצאות בדיקות עומסים. לדוגמה, לקוח מסחר אלקטרוני אחד חסך $12,000 בחודש בעלויות AWS לאחר שזיהינו ותיקנו צוואר בקבוק במסד הנתונים. פרויקטים טיפוסיים של בדיקות עומסים מתחילים ב-$2,000 ויכולים להגיע עד $10,000 בהתאם למורכבות.

בעיות שאנחנו פותרים

קפיצות אחזור פתאומיות. במהלך קמפיין, זמני התגובה קופצים מ-200ms ל-5s. אנו מאתרים את צוואר הבקבוק המדויק – שאילתות מסד נתונים איטיות, מטמונים מוגדרים שגוי, או pools חיבור לא מספקים.

קריסות מחוסר זיכרון. תחת עומס בינוני, היישום קורס עם // tests/stress/breaking-point.js import http from 'k6/http' import { check, sleep } from 'k6' import { Rate, Trend, Counter } from 'k6/metrics' const errorRate = new Rate('errors') const requestsPerSecond = new Counter('requests_per_second') export const options = { stages: [ { duration: '2m', target: 50 }, { duration: '3m', target: 50 }, { duration: '2m', target: 100 }, { duration: '3m', target: 100 }, { duration: '2m', target: 200 }, { duration: '3m', target: 200 }, { duration: '2m', target: 400 }, { duration: '3m', target: 400 }, { duration: '2m', target: 800 }, { duration: '3m', target: 800 }, { duration: '2m', target: 1600 }, { duration: '3m', target: 1600 }, { duration: '5m', target: 50 }, { duration: '3m', target: 0 }, ], thresholds: { http_req_duration: [ { threshold: 'p(95)<2000', abortOnFail: false }, ], errors: [ { threshold: 'rate<0.1', abortOnFail: false } ] } } const BASE_URL = __ENV.BASE_URL || 'http://localhost:3000' export default function() { const responses = http.batch([ ['GET', `${BASE_URL}/api/products?limit=20`], ['GET', `${BASE_URL}/api/categories`], ]) responses.forEach(r => { check(r, { 'status 2xx': (r) => r.status >= 200 && r.status < 300 }) errorRate.add(r.status >= 400) }) requestsPerSecond.add(2) sleep(0.1) } export function handleSummary(data) { const stages = analyzeStages(data) return { 'stress-results.json': JSON.stringify(data, null, 2), stdout: generateReport(stages) } } function generateReport(stages) { return ` === STRESS TEST REPORT === Breaking Point Analysis: ${stages.map(s => ` VUs: ${s.vus} | p95: ${s.p95}ms | Errors: ${(s.errorRate*100).toFixed(1)}%`).join('\n')} ` } . אנו עוקבים אחר דליפות זיכרון ומתקנים מגבלות תהליך.

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

איך אנחנו עושים את זה

אנו משתמשים ב-k6 – כלי שצורך פי 5 פחות משאבים מ-Apache JMeter ומתעלה עליו פי 5. k6 כתוב ב-Go ותומך בסקריפטים של JavaScript, מה שהופך אותו לאידיאלי עבור CI/CD. התהליך כולל ארבעה שלבים:

1. קו בסיס. הרצת עומס רגיל (50–70% מהשיא הצפוי) ותיעוד אחזור p95, שיעור שגיאות, CPU/זיכרון.
2. עלייה הדרגתית. הגדלת עומס ב-10–20% כל 2–5 דקות עד להופעת שגיאות או עיכוב קריטי.
3. מציאת נקודת שבירה. המשך עד ששיעור השגיאות >5% או אחזור >פי 5 מקו הבסיס.
4. התאוששות. הסרת עומס ומדידת זמן החזרה לשגרה.

להלן תרחיש k6 לבדיקת עומסים עם עלייה הדרגתית עד 1600 משתמשים וירטואליים:

// tests/stress/breaking-point.js
import http from 'k6/http'
import { check, sleep } from 'k6'
import { Rate, Trend, Counter } from 'k6/metrics'

const errorRate = new Rate('errors')
const requestsPerSecond = new Counter('requests_per_second')

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '3m', target: 50 },
    { duration: '2m', target: 100 },
    { duration: '3m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '3m', target: 200 },
    { duration: '2m', target: 400 },
    { duration: '3m', target: 400 },
    { duration: '2m', target: 800 },
    { duration: '3m', target: 800 },
    { duration: '2m', target: 1600 },
    { duration: '3m', target: 1600 },
    { duration: '5m', target: 50 },
    { duration: '3m', target: 0 },
  ],
  thresholds: {
    http_req_duration: [
      { threshold: 'p(95)<2000', abortOnFail: false },
    ],
    errors: [
      { threshold: 'rate<0.1', abortOnFail: false }
    ]
  }
}

const BASE_URL = __ENV.BASE_URL || 'http://localhost:3000'

export default function() {
  const responses = http.batch([
    ['GET', `${BASE_URL}/api/products?limit=20`],
    ['GET', `${BASE_URL}/api/categories`],
  ])

  responses.forEach(r => {
    check(r, {
      'status 2xx': (r) => r.status >= 200 && r.status < 300
    })
    errorRate.add(r.status >= 400)
  })

  requestsPerSecond.add(2)
  sleep(0.1)
}

export function handleSummary(data) {
  const stages = analyzeStages(data)
  return {
    'stress-results.json': JSON.stringify(data, null, 2),
    stdout: generateReport(stages)
  }
}

function generateReport(stages) {
  return `
=== STRESS TEST REPORT ===
Breaking Point Analysis:
${stages.map(s => `  VUs: ${s.vus} | p95: ${s.p95}ms | Errors: ${(s.errorRate*100).toFixed(1)}%`).join('\n')}
`
}

עבור מרקטפלייס, המערכת הייתה יציבה ב-500 RPS אך לקח 4 דקות להתאושש לאחר הסרת העומס. האבחון חשף pools חיבור PostgreSQL מוגדרים שגוי. לאחר האופטימיזציה, זמן ההתאוששות ירד ל-30 שניות והתפוקה עלתה ל-1500 RPS.

תהליך והערכת עלות

העבודה שלנו כוללת את השלבים הבאים:

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

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

לוחות זמנים

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

טעויות נפוצות ורשימת בדיקה

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

#!/bin/bash
# scripts/monitor-stress-test.sh
TARGET_HOST="app-server-ip"
INTERVAL=10
while true; do
  TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  ssh $TARGET_HOST "
    echo -n '$TIMESTAMP '
    echo -n 'cpu:'; top -bn1 | grep 'Cpu(s)' | awk '{print \$2}'; echo -n ' '
    echo -n 'mem:'; free | grep Mem | awk '{print \$3/\$2 * 100}'; echo -n ' '
    echo -n 'load:'; cat /proc/loadavg | awk '{print \$1}'
    echo -n 'conns:'; ss -s | grep -o 'estab [0-9]*' | awk '{print \$2}'
  "
  ssh $TARGET_HOST "
    PGPASSWORD=pass psql -U app -d appdb -t -c \"
      SELECT 'active_queries:', count(*) FROM pg_stat_activity WHERE state = 'active' AND query NOT LIKE '%pg_stat%';
      SELECT 'long_queries:', count(*) FROM pg_stat_activity WHERE state = 'active' AND query_start < NOW() - interval '5 seconds';
      SELECT 'locks:', count(*) FROM pg_locks WHERE NOT granted;
    \"
  "
  sleep $INTERVAL
done | tee stress-monitor.log

ניתוח תוצאות עם Prometheus ו-Grafana

אנו מזרימים מדדי k6 ל-Prometheus באמצעות Remote Write ובונים דשבורדים ב-Grafana. דוגמת PromQL:

# RPS в реальном времени
rate(k6_http_reqs_total[30s])

# Error rate по времени (найти момент деградации)
rate(k6_http_req_failed_total[30s]) / rate(k6_http_reqs_total[30s])

# p95 latency в реальном времени
histogram_quantile(0.95, rate(k6_http_req_duration_seconds_bucket[30s]))

סקריפט Python למציאת נקודת השבירה אוטומטית:

# analyze_stress_results.py
import json
import pandas as pd

def analyze_breaking_point(results_file):
    with open(results_file) as f:
        data = json.load(f)
    metrics = data['metrics']
    analysis = {
        'max_rps_before_errors': find_max_sustainable_rps(metrics),
        'error_threshold_rps': find_error_threshold(metrics),
        'latency_degradation_point': find_latency_degradation(metrics),
        'recovery_time_seconds': find_recovery_time(metrics),
    }
    print("=== Breaking Point Analysis ===")
    print(f"Max sustainable RPS (< 1% errors): {analysis['max_rps_before_errors']}")
    print(f"Error threshold RPS: {analysis['error_threshold_rps']}")
    print(f"p95 > 1s at RPS: {analysis['latency_degradation_point']}")
    print(f"Recovery time after load removal: {analysis['recovery_time_seconds']}s")
    if analysis['max_rps_before_errors'] < 100:
        print("\n[!] LOW capacity. Consider: DB connection pooling, caching, horizontal scaling")
    elif analysis['recovery_time_seconds'] > 120:
        print("\n[!] SLOW recovery. Consider: circuit breakers, graceful degradation")
    return analysis

מה כלול בעבודה

• תיעוד נקודת השבירה (RPS, אחזור, שיעור שגיאות)
• דשבורדים של Grafana עם היסטוריית בדיקות וקורלציית מדדים
• המלצות אופטימיזציה ממוינות לפי עדיפות (קריטי / רצוי)
• בדיקה חוזרת לאחר יישום שינויים
• דוח זמן התאוששות
• אספקה מובטחת תוך 2 ימי עסקים

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

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

צווארי בקבוק טיפוסיים ואבחון

השוואת כלים

k6 עדיף פי 5 על JMeter לבדיקות עומסים מבחינת יעילות משאבים ואוטומציה.

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

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