تست بار و استرس

1) شرایط و اهداف

تست بار - تست در محدوده کاری (هدف RPS/رقابت) در برابر SLO (به عنوان مثال، p95 <200 ms، نرخ خطا <0. 5%).
تست استرس - فراتر رفتن (قبل/بیش از اشباع CPU/DB/شبکه)، مشاهده مکانیک تخریب و بازیابی.
آزمون اسپایک - انفجار شدید بار (× N برای دقیقه).
خیس/استقامت - طولانی مدت (ساعت/روز) برای پیدا کردن نشت، رانش GC، تکه تکه شدن، رشد صف.
آزمون ظرفیت - محاسبه فلات توان (نقطه اشباع) و ذخایر.

اهداف: تایید SLO، رفع فلات، درک تنگناها، کالیبراسیون خودکار مقیاس و محدودیت ها.

2) مدل ترافیک: باز در مقابل بسته

Closed model (concurrency-driven): تعداد ثابتی از کاربران مجازی (VUs)، هر کدام پس از پاسخ، زمان فکر کردن را ایجاد می کنند.
مدل باز (نرخ ورود): نرخ ثابت درخواست (RPS)، صرف نظر از پاسخ.

در فروش، اغلب جهان «باز» (کاربران به عنوان آنها می آیند)، بنابراین اولویت به مدل سازی نرخ ورود برای API/وب داده شده است.

قانون لیتل: L = λ W

'L' تعداد متوسط درخواست به طور همزمان سرویس است،

«λ» - شدت (RPS)،

«W» میانگین زمان پاسخ است.
از این رو ارزیابی رقابت لازم ژنراتور: "همزمانی ≈ target_RPS p95_latency'.

3) معیارها: آنچه ما اندازه گیری می کنیم

SLI تاخیر: p50/p90/p95/p99 و دم p99. 9; جدا برای مسیرهای «گرم» و «سرد».
خطاها: '5xx', '4xx' (معتبر/نامعتبر), وقفه, ساقط.
توان: RPS پایدار، جریان خروجی/بایت.
منابع: CPU، RAM/heap، مکث GC، IOPS دیسک/لات، پهنای باند شبکه، تعداد اتصالات/FD.
صف ها و Backprescher: عمق، زمان انتظار، تعداد درخواست های ریخته شده/محدود.
راندمان حافظه پنهان: ضربه/خانم، طوفان گرم.
DB/caches/صف: درخواست p95، قفل، درگیری، استفاده از استخر.

4) پایه ها و داده ها

هم ارزی پیکربندی: نسخه های نرم افزاری، محدودیت ها (uLimit، conntrack)، پیکربندی JVM/GC، استخرها.
توپولوژی: LBs، CDN، WAF، TLS، همان شبکه «هاپ».
داده ها: توزیع واقعی (اندازه اشیاء، کلیدهای «گرم «/» سرد «، منطقه ای بودن).
شروع سرد/گرم/گرم: اجرای فردی ؛ مطمئن شوید که «سرد» را آزمایش کنید.
جداسازی پس زمینه: غیر فعال کردن مشاغل/cronomes بی ربط و یا حساب برای اثر آنها.

5) سناریوها (پروفایل های بار)

1. خط پایه: شتاب گام برای هدف قرار دادن RPS، نگه داشتن 10-30 دقیقه.
2. رمپ و نگه دارید: رشد صاف به X٪ بالاتر از هدف، حفظ → تجزیه و تحلیل دم.
3. اسپایک: × فوری 2- × 5 چلپ چلوپ برای 1-5 دقیقه، سپس بازگشت.
4. استرس تا شکست: گامهایی تا شکست رفع اولین نقطه شکست SLO و نقطه «شکستن».
5. خیس کردن: 6-24 ساعت با تغییرات ترافیک (روز/شب)، مراقب چهره/رانش باشید.
6. مخلوط: مخلوط نقاط پایانی با توزیع واقعی (Zipf/pareto)، وزن های مختلف.

6) فرآیند گام به گام

SLO و پروفایل های ترافیک هدف را تعریف کنید.
مدل بار (باز/بسته) را انتخاب کنید، نرخ ورود یا VU را تنظیم کنید.
آماده سازی داده ها و حالت های «گرم «/» سرد «.
تنظیم تله متری (مسیرهای پیاده روی/متریک/سیاهههای مربوط)، ارتباط با اجرای آزمون.
گرم کردن و در حال اجرا، جمع آوری مصنوعات (پروفیل CPU/heap، نمودار شعله، توضیح/آهسته سیاهههای مربوط DB).
تجزیه و تحلیل تنگنا، تشکیل آیتم های عمل.
Reprogon پس از رفع، به روز رسانی پایه و playbook ظرفیت.

7) تنگناها و رفع معمولی

خدمات CPU محدود: پروفایل → حذف توابع داغ، تخصیص، شاخه ؛ برداری، ساختار کش پسند.
شبکه/TLS: زنده نگه داشتن، HTTP/2/3، اتصال به شبکه، زمان بندی صحیح، کاهش چت.
DB: شاخص ها، دسته بندی، پرس و جو آماده، استخر اتصال، جداسازی R/W، ذخیره سازی نتیجه، deduplication پرس و جو.
Caches: اندازه، TTL، درخواست هماهنگی، حفاظت از طوفان، گرم شدن، توپ های منطقه ای.
صف/کارگزاران: محدودیت پذیرش/موازی، اندازه دسته، مصرف کنندگان idemotent، سقف DLQ.
Garbatage/مکث: تنظیم GC، اجاره بافر، جمع آوری شی در محدوده معقول.
I/O/دیسک: I/O ناهمزمان، فشرده سازی، فشرده سازی پاسخ ها با سطح معقول.

8) محدودیت و حفاظت

زمان بندی بودجه: از بالا به پایین برای جلوگیری از آبشار.
محدودیت نرخ/سطل نشانه: تخریب قابل پیش بینی به جای «مرگ طولانی».
قطع کننده مدار و سایه اشباع اولویت پایین.
فشار برگشتی: سیگنالها و محدود کردن همزمانی در عمق زنجیره.
Bulkheads: استخرهای جدا شده برای نقاط پایانی بحرانی.
Idempotency: کلید برای تکرار امن در زیر retraces.

9) ابزار و زمان انتخاب آنها

k6 - JS laconic، پشتیبانی عالی برای نرخ ورود، ادغام و نمودار.
Gatling - Scala DSL، ژنراتور با کارایی بالا.
JMeter - انعطاف پذیر، اکوسیستم غنی ؛ مناسب برای پروتکل ها/پلاگین ها.
Locust - اسکریپت های پایتون، مناسب برای منطق جریان پیچیده کاربر.
Vegeta/hey/wrk - میکروبنشی و نقطه در HTTP اجرا می شود.
tc/netem، toxiproxy - تزریق تخریب شبکه.
Flamegraph/profiler - نقاط داغ CPU/heap را جستجو کنید.

10) نمونه (طرح)

k6 (مدل باز، نقاط پایانی مخلوط)

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

export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};

export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}

Gatling (مراحل و سنبله)

scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))

برنامه بار (اسکلت YAML)

yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m

11) اتوماسیون و چرخه عمر

Perf-smoke در هر PR (اجرای کوتاه از نقاط پایانی کلیدی).
«ظرفیت» شبانه بر روی صحنه با گزارش ها و مصنوعات مشخصات اجرا می شود.
Gates در CI/CD: ساخت فایل هنگام regressing p95/p99> X% از خط پایه یا نرخ خطا رشد.
نسخه از خطوط پایه و ذخیره سازی پروفیل/flamegraphs به عنوان مصنوعات.
برچسب های مرتبط: کدام سرویس/نقطه پایانی پوشش داده شده است، کدام مشخصات ترافیک استفاده می شود.

12) ضد الگوهای

ژنراتور و سرویس تست در همان دستگاه → نتایج تحریف شده.
فقط مدل بسته (VU ها) برای APIbacks → undershooting و misjudgment.
اجرا می شود بر روی یک پایگاه داده خالی/کش بدون شروع سرد.
هیچ توزیع واقع گرایانه ای وجود ندارد (همه پرس و جوها یکسان هستند).
بدون تله متری (RPS/تاخیر فقط در سمت ژنراتور).
مقایسه بدون خطوط پایدار و کنترل محیط زیست.
«بهینه سازی» از طریق افزایش زمان وقفه به جای اصلاح علت.

13) چک لیست معمار

1. SLO و بار معمولی/پیک تعریف شده است ؟

2. آیا مدل صحیح (باز/بسته) انتخاب شده و مشخصات ترافیک توصیف شده است ؟

3. پایه در پیکربندی و توپولوژی معادل است، آیا حالت سرد/گرم وجود دارد ؟

4. تله متری و پروفایل های فعال، تست زخم برچسب گذاری شده است ؟

5. اجرا می شود: پایه/رمپ/سنبله/استرس/خیس شدن - پوشش داده شده ؟

6. آیا نقاط اشباع ثابت هستند و حاشیه ایمنی برنامه ریزی شده است ؟

7. محدودیت های پیکربندی شده، شکن ها، backprescher، idemotency، سیاست های سایه ؟

8. آیا دروازه های CI برای رگرسیون p95/p99 و میزان خطا وجود دارد، آیا خطوط پایه versioned ؟

9. پس از رفع - به روز رسانی مجدد و قدرت playbook ؟

10. زوم خودکار و برنامه اضطراری مستند شده است ؟

نتیجه گیری

تست بار و استرس یک بار «مسابقه» نیست، بلکه تمرین مهندسی مداوم است. یک مدل ترافیکی واقع بینانه، ایستگاه های صحیح، تله متری و اتوماسیون در CI/CD، عملکرد را از «سحر و جادو مخفی» به توانایی مبتنی بر متریک تبدیل می کند: شما می دانید که سقف شما کجاست، چقدر امن است و چه تغییراتی واقعا تجربه کاربر را بهبود می بخشد.