בדיקת עומס ופרופילי לחץ
תקציר
בדיקת עומס היא מבחן מערכת של ביצועים והתאוששות תחת תרחישים מציאותיים וקיצוניים. הבסיס להצלחה: מודל התנועה הנכון (פתוח נגד סגור), SLO קבוע, מטרי טהור (letency/product/images/rovation), מידע מייצג, אוטומציה וחזרה. התוצאה אינה ”דמות RPS”, אלא פתרון: איפה צווארי הבקבוק, כמה עולה הביצועים, איפה סף הכישלון ואיך להזיז אותו.
SLO/SLI ומדדי המטרה
SLO (דוגמה): p95 API, 250 ms, p99 ms 600 ms; שגיאה ברישום 0. 3 %/30 ימים.
SLI: latency (p50/p95/p99), dirput (RPS/CPS/QPS), רוויה (CPU/Heap/GC/FD/conn), DB (5xx, timeout), DB (מנעולים, שאילתות איטיות), callescue (hit-ratio).
שגיאה ורוויה מעוררים (לדוגמה, CPU> 75% או עומק תור> X # Desgradation).
סוגים של בדיקות
1. Baseline/Benchmark - שירות יחיד/נקודת סוף, תנאים ”אידיאליים”.
2. עומס - ”יום עבודה” מציאותי + רמפה למעלה/רמפה למטה.
3. לחץ - להגביר את העומס להשפלה וקיבעון נקודת שבירה.
4. קפיצה חדה (x2-x10 בשניות/דקות).
5. Soak/Endurance - טווח ארוך (8-72 h): דליפות זיכרון, סחף אחורי.
6. קיבולת - העמסת שלב לעקומת ביצועים ותכנון קיבולת.
7. הידרדרות/מיקס כאוס - עומס + כשלים חלקיים (מסד נתונים איטי, טיפת מטמון, ”קרס” אפלינק).
מודלי תנועה: פתוח נגד סגור
מודל פתוח (יותר מציאותי עבור האינטרנט): משתמשים מגיעים עם עוצמות תורשתיות (Poisson-like stream). אם המערכת מאטה, הבקשות מצטברות, לא ”קפואות”.
מודל סגור - מספר קבוע של משתמשים וירטואליים (VUs) עם זמן חשיבה. כאשר העיכוב גדל, RPS נופל באופן מלאכותי - בזהירות עם מסקנות.
המלצה: עבור APIs front-end משתמשים במודל פתוח (k6.6 &posphale arrival-rate), עבור תסריטים סינכרוניים פנימיים - לשלב עם סגור.
טען פרופילים (תבניות)
”יום רגיל”: רקע בסיסי + תנודות יומיות.
”אירוע שיא”: 10-30 דקות לפני ההתחלה (חימום), קפיצה חדה בהתחלה, הרמה, זנב.
”טורניר/זרם”: שלבי סולם, פסגות חוזרות במרווחים.
”הידלדלות תשתית”: מחצית המטמון ריק, אזור אחד כבוי, PSP Latency גדל.
”כשל”: התנועה זורמת להגנה תוך 1-5 דקות; בודק סופות בקנה מידה אוטומטי/HPA/Retry.
נתוני סביבה והכנה
נתוני מבחן: קרדינליות מציאותית (ספקים, מטבעות, מדינות), שדות מלוכלכים, הפצות שאילתות (Pareto/Zipf).
סודות/PII: אנונימיות; מפתחות/PSP - ארגז חול.
סביבה: עמדה ייעודית, בידוד מאינטגרציה (דקירה/דקירה), גרסאות קבועות.
תצפיות: Metrics (פרומתאוס), logs (לוקי/ELK), עקבות (OTEL). רישום זיהוי מבנה בתגובות.
Antistorm Reprays ו Idempotence
רטריי רק לפעולות אידמפוטנטיות; הגדרת תקצוב מחדש (לדוגמה: 10% מהתנועה).
גיבוי מעריכי + jitter; ”קורסת” גטים זהים.
לתשלומים - מפתחות אידמפוטנטים ומדינות מפורשות.
הגנה מפני עדר רעמים: מנעולי מטמון, SWR, סמפורות מקומיות.
כלים ותבניות
k6 (תסריט, מודל פתוח, דיווח טוב), Locust (תסריטי פייתון), Gatling (סקאלה), JMeter (מגוון רחב של פרוטוקולים).
פרוטוקולים: HTTP/1. 1/2/3, GRPC, WebSocket, TCP/UDP; שרת הדחיפה לא בודק ”כמו לקבל”.
דור תנועה: קנה מידה אופקי של גנרטורים, שליטה על צוואר בקבוק רשת.
הסרת פרופילים: pprof/async-profiler/ebpf תחת עומס, נתיבי OTEL.
javascript import http from 'k6/http';
import {check, sleep} from 'k6';
export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};
export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}הליך
1. השערה # אילו צווארי בקבוק הם סביר (מעבד, DB, מטמון, רשת, TLS, GC).
2. תרחישים/מסלולים, מניות תנועה, מודלים (פתוח/סגור), נתונים.
3. חימום מטמון/חיבורים/TLS/מתורגמנים.
4. הגדלה של השלב הבא לעוצמת המטרה.
5. אוסף מישורי של מדדים יציבים ועקבות.
6. לחץ/ירידה = למצוא נקודת שבירה, לצפות בקנה המידה האוטומטי.
7. לנתח מדדים, פלמגרף, לדווח ולשנות תוכנית.
8. Repruf # לחזור דרך צינור CI (Region Perf).
ניתוח תוצאות
טעינת עקום השהייה/שגיאה: מחפש את המרפק (קיבולת).
פירוק latency: רשת (DNS/TLS/connect), פרוקסי, יישום, מסד נתונים, שיחות חיצוניות.
רוויה: CPU> 75-85%, GC pause> p95, I/O מחכה, תור משימה.
אלסטיות: זמן תגובה אוטומטי (HPA/KEDA), התחלה קרה, חימום מטמון.
עלות: 1000 $ RPS ביעד SLO, תחזית תקציב שיא.
פרקטיקות הנדסה
אינדיקטורים של הידרדרות: ”זנבות” p99, צמיחת תור, ירידה ביחס פגע, צמיחה של ניסיונות מגש מחדש.
אל תשתלט על קונפליקטים: גבולות תיאור קבצים, Sysctl, conn-pool, "reusport', שרשראות TLS, OCSP.
DB: אינדקסים/תוכניות/מטמון שאילתות, מאגר חיבור, פעולות אצווה, תרמיל גב על יצרנים.
מטמונים: גודל/מדיניות פינוי, מפתחות חמים, שכפול.
רשת/קצה: HTTP/2/3, חידוש של 70%, ברוטלי, מפתח מטמון CDN, מטמון.
תצפית תחת עומס
מטריצות: מערכת (CPU/Mem/IO), זמן ריצה (GC/Heap), רשת (RTT/loss/ECN), L7 (p95/99, 5xx/429), תורים, אשכולות/מטמון מסד נתונים.
שבילים: כולל דגימה על ”זנבות” (מבוססי זנב), סימונים מזהים/קנריים.
יומנים: צבירה של שגיאות עם מגבלת נפח (כדי לא ”FORDOSOR” log-pipeline).
ניסויים: דגלי תכונה ותצורות יש להקליט בדו "ח.
אוטומציה ו CI/CD
עבודות Perf ב CI (עשן 3-5 דקות, לילה 30-60 דקות, השריה שבועית).
גבולות סובלנות: latency/image/resources # ”לשבור את המבנה” ברגרסיה.
חפצים: גרפים, פלמגרפיים, פרופילים, דו "חות JSON (k6/jtl).
ורסינציה של נתונים ותסריטים, סקירת יחסי ציבור של תסריטי פרף.
iGaming/fintech ספציפי
טורנירים/גפרורים: spike + plateau; TLS/DNS/CDN מתחמם, גבולות בריכה מוגברים, מסלולים אפורים עבור רובוטים.
תשלומים/PSP: גבולות ארגז חול, אידמפוטנטיות, פסקי זמן נוקשים; בדיקת דלגרד-מוד (מטמון ספריה, תורים).
זכרונות/אירועים: אטומיות ועקביות, לא לוקח, עומס על RNG/לוחות מוביל.
נגד הונאה/AML: טען על כללים/ניקוד ML, תרמיל גב, שכפול אירועים.
רגולציה: רישום מדדים וגרסאות בפסגות, דיווחים לביקורת.
שיגור רשימה
[ ] SLO/SLI וקווים אדומים (שגיאה/לאטנסיביות/רוויה).[ ] תרחישי טעינה ופרופילים מאושרים (פתוח/סגור, ספייק/ספייק/לחץ).[ ] דאטה ריאליסטי, מח "ש במסכה, ארגז חול/מדומה אינטגרטיבי.[ ] תצפית מוכנה: מדדים/שבילים/רישומים, תגי שחרור.[ ] תצורות מערכת (ulimit/sysctl/pols) מתועדות.[ ] תוכנית חימום אוטומטית/מטמון וקריטריונים גלגול.[ ] התראות סף ותוכנית תורנית.[ הוכנה תבנית דיווח ] (תרשימים, מסקנות, פעולות).שגיאות נפוצות
המבחן בדגם סגור מייצר תוצאה ”ירוקה”, והמוצר יורד (לא ניתן להתעלם מהמודל הפתוח).
נתונים לא מיוצגים (ספק מטבע אחד) = מסקנות שגויות.
אפס הכנה: מטמונים קרים/TLS/חיבורים = איחור מוגזם בהתחלה.
רטריי ללא גבולות * סערה ומפל נופלים.
אותם פרופילים לכל השירותים. מדלגים על ”נקודות חמות” אמיתיות.
היעדר ספוג רץ = דליפות זיכרון וסחף אינם נראים לעין.
תוצאות אטומות: אין עקבות/פלמגרפס = אין אפשרות לאתר צוואר בקבוק.
ספרי משחקים מיני
הגדרת נקודת שבירה
1. צעדים של 10-20% מהעומס כל 5-10 דקות. 2) לתקן את הרגע שבו p95 עולה בחדות ושגיאות> SLO. 3) הסר פרופילי מעבד/DB/מטמון. 4) תוכנית אופטימיזציה וחזרה.
לרטון בסופות מגש מחדש
1. להגביל מחדש תקציב ולאפשר גיבוי + jitter. 2) הזן בקשה קורסת/SWR. 3) לאפשר ”מצב דלגראד” (פונקציונליות מוגבלת). 4) בדיקת אידמפוטנטיות כפולה.
אירוע שיא (טורניר) - תכנית מראש
1. לחמם את CDN/DNS/TLS/בריכות. 2) להגדיל את HPA המטרה, להכין רזרבה. 3) מגבלות קצב נפרדות עבור בוטים. 4) לוחות מחוונים של מצב שיא, גשר תקשורת בכוננות.
לספוג בלילה
1. 8-12 שעות של עומס יציב. 2) צג ערימה/FD/conn/GC-pauses. 3) בדוק את הדלתה p95 והיחס פגע. 4) לתקן דליפות ולהיסחף.
תוצאות
בדיקת עומס היא תהליך קבלת החלטות הנדסי, לא "מירוץ ל-RPS. "פרופילים אמיתיים מודל (במיוחד המודל הפתוח), ללכוד SLOs, לקחת מדדים ועקבות, לחפש את הברך ביצועים, ולספור את עלות הביצועים. ריצות אוטומטיות, נסיגות נגד סערה ותכנון אירועי שיא - בדרך זו הפלטפורמה תהיה צפויה ויציבה ברגעים המלחיצים ביותר.