בדיקת עומס ופרופילי לחץ

תקציר

בדיקת עומס היא מבחן מערכת של ביצועים והתאוששות תחת תרחישים מציאותיים וקיצוניים. הבסיס להצלחה: מודל התנועה הנכון (פתוח נגד סגור), 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.

דוגמה קטנה k6 (מודל פתוח + ספייק):

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, לקחת מדדים ועקבות, לחפש את הברך ביצועים, ולספור את עלות הביצועים. ריצות אוטומטיות, נסיגות נגד סערה ותכנון אירועי שיא - בדרך זו הפלטפורמה תהיה צפויה ויציבה ברגעים המלחיצים ביותר.