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

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

1) چرا شما به آن نیاز دارید

• تأیید ظرفیت (چند جلسه RPS/رقابتی که سیستم در برابر SLO مقاومت می کند).
• پیدا کردن تنگناها (CPU/IO/DB/شبکه/قفل/استخر).
• تنظیم بودجه عملکرد و دروازه در CI/CD.
• کاهش خطر انتشار (رگرسیون p95/p99، رشد اوج خطا).
• ظرفیت برنامه/هزینه (مقیاس و ذخایر).

2) انواع تست های perf

بار: ترافیک واقع بینانه نزدیک به قله ؛ اعتبار سنجی SLO

استرس: رشد به/بالاتر از حد → رفتار تخریب که در آن می شکند.
اسپایک: پرش بار سریع → کشش/مقیاس خودکار.
خیس/استقامت: ساعت/روز → نشت، تکه تکه شدن، رانش تاخیر.

ظرفیت/مقیاس پذیری: چگونه توان/تاخیر با مقیاس پذیری تغییر می کند ؛ قانون آمدال/گاستافسون

دود perf: کوتاه «دود» اجرا بر روی هر آزادی (شأن عملکرد).

3) مدل های تولید ترافیک

VUs ثابت/همزمانی: «N» کاربران، هر ساخت درخواست به → صف در مشتری. خطر پنهان شدن بیش از حد

نرخ ورود: جریان برنامه های کاربردی با شدت λ (req/s)، همانطور که در زندگی واقعی است. برای API های عمومی صحیح تر است.

قانون لیتل: «L = λ × W».
برای استخر/خدمات، حداقل موازی ≈ 'λ × W' (اضافه کردن 20-50٪ از موجودی).
جایی که «λ» توان عملیاتی است، «W» میانگین زمان سرویس است.

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

ترکیب سفر کاربر: سهام اسکریپت ها (ورود، مرور، سپرده، پرداخت و...).
زمان تفکر: مکث کاربر (توزیع: نمایی/lognormal).
مشخصات داده ها: اندازه پاسخ ها، بارگیری، تنوع پارامترها.
همبستگی: مراحل پیوند (کوکی ها/نشانه ها/شناسه) به عنوان یک جریان واقعی.
سرد/گرم/کش داغ: اجرا می شود فردی است.
خواندن در مقابل نوشتن: تعادل خواندن/ثبت، idemotency برای retrays.
چند منطقه: RTT، توزیع توسط POP/ASN.

5) محیط آزمایش

جداسازی: پایه در توپولوژی/تنظیمات نزدیک به محصول است (اما محصول را «ضرب و شتم» نمی کند).
داده ها: PII پوشش، حجم، شاخص به عنوان در فروش.
ژنراتور بار: در برابر CPU/شبکه استراحت نکنید ؛ دونده های توزیع شده، هماهنگ سازی زمان.
قابلیت مشاهده: معیارها/مسیرهای پیاده روی/سیاهههای مربوط، synthetics در محیط، صادرات پروفایل CPU/heap.

6) معیارها و SLI

توان عملیاتی: RPS/معاملات/ثانیه

تاخیر: p50/p95/p99، TTFB، زمان سرور در مقابل شبکه.
خطاها: سهم خطاهای 5xx/4xx/domain.
اشباع: CPU، avg بار، GC، IOps دیسک/تاخیر، شبکه، صبر کنید استخر.
SLI کسب و کار: موفقیت سپرده ≤ 5s، تایید سفارش ≤ 2s.

آستانه ها را از SLO (به عنوان مثال، "99. 95٪ ≤ 300 میلی ثانیه")، میزان سوختگی را در طول اجرا نظارت کنید.

7) پیدا کردن تنگناها (تکنیک)

1. به طور مداوم سیستم را با 60-80٪ از بار هدف گرم کنید.
2. افزایش در مراحل (سطح شیب دار) → رفع که در آن p95/p99 و نرخ خطا رشد می کنند.

• صف در استخر (DB/HTTP)
• رشد WAIT/قفل (DB)،
• GC-مکث/پشته،
• انتقال مجدد شبکه/از دست دادن بسته،
• تاخیر دیسک/کش از دست می رود.
• 4. محلی سازی: جستجوی دودویی با مسیر پرس و جو، پروفایل (CPU/-/lock-profile).
• 5. رفع «بطری» → تنظیم → تکرار اجرا.

8) رفتار تحت استرس

تخریب برازنده: محدودیت ها، قطع کننده مدار، صف فشار به عقب، پذیرفته شده برای پردازش.
Retrays: حداکثر 1، تنها idempotent ؛ لرزش ؛ بودجه بازپرداخت ≤ 10٪ از RPS.
Fail-open/Fail-closed: برای وابستگیهای غیر بحرانی، اجازه fail-open (cache/stubs) را میدهد.
شکست آبشار: انزوا از استخر/سهمیه (bulkhead)، timeouts سریع، «صاف» غیر فعال کردن توابع (پرچم ویژگی).

9) ابزار (انتخاب برای کار)

k6 (جاوا اسکریپت، باز/باز مدل، سریع، مناسب در CI).
JMeter (غنی از اکوسیستم، GUI/CLI، پلاگین ها، اما سنگین تر).
Gatling (اسکالا DSL، عملکرد بالا).
Locust (پایتون، انعطاف پذیری اسکریپت).
Vegeta/hey/wrk (میکرو نیمکت و بررسی سریع).

قانون: یک ابزار «اصلی» + CLI نور برای قلم دود در PR.

10) نمونه (قطعه)

10. 1 k6 (مدل باز با نرخ ورود)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (ایده مشخصات)

Thread Group + Step Thread или Thread Concurrency (مانند باز کردن).
پیش فرض های درخواست HTTP، مدیر کوکی، مجموعه داده CSV.

Backend Listener → InfluxDB/Grafana ؛ ادعای زمان/کد

10. 3 ملخ (پایتون)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) داده ها، همبستگی، آماده سازی

داده های بذر: دایرکتوری ها، کاربران، تعادل، نشانه ها - مانند فروش.
PII ماسک/ناشناس ؛ تولید مصنوعی در بالای توزیع واقعی.
همبستگی: شناسه ها/نشانه ها را از پاسخ ها (RegExp/JSONPath) استخراج کنید و در مراحل بعدی استفاده کنید.

12) قابلیت مشاهده در طول اجرا

داشبورد قرمز (نرخ، خطا، مدت زمان) در طول مسیر.
نمونه ها - انتقال از معیارها به ردیابی (trace_id).
سیاهههای مربوط به خطا: نمونه برداری + تجمع، تکراری/idemotence.
سیستم: CPU/GC/هیپ، دیسک/شبکه، استخر صبر کنید.
DB: نمایش داده شد بالا، قفل، اسکن شاخص، نفخ.

13) دروازه های اتوماسیون و عملکرد

CI: اجرا می شود کوتاه در ادغام (به عنوان مثال،. k6 2-3 دقیقه) با آستانه.

شبانه/هفتگی: خیس خوردن/استرس طولانی در یک محیط جداگانه ؛ گزارش ها و روند

انتشار قناری: تجزیه و تحلیل SLO (نرخ خطا، p95) به عنوان «دروازه» ارتقاء.
رگرسیون: پایه در مقابل ساخت فعلی ؛ هشدار در خرابی> X٪.

14) برنامه ریزی ظرفیت و هزینه

Curves throughput → latency: تعریف نقطه زانو - پس از آن p99 به شدت رشد می کند.
مقیاس پذیری: اندازه گیری کارایی مقیاس پذیری (RPS delta/node delta).
هزینه: «RPS در هر دلار/ساعت»، رزرو برای رویدادهای اوج + DR-رزرو.

15) ضد الگوهای

ضرب و شتم به تولید بدون کنترل و یا آزمون در یک محیط «خالی»، نه مانند تولید.
مدل بسته با VU های ثابت پنهان کردن بیش از حد.
کمبود زمان فکر/داده → بازدید کش غیر واقعی، و یا بالعکس - طوفان به منبع.
یک اسکریپت «/پینگ «به جای جریان سفارشی.
عدم مشاهده: «ما فقط RPS و تاخیر متوسط را می بینیم».
Retrays کنترل نشده → خود DDoS.
مخلوط کردن تست و بهینه سازی بدون اصلاح فرضیه ها/تغییرات.

16) چک لیست (0-30 روز)

0-7 روز

SLI/SLO را تعریف کنید و پروفایل های ترافیکی (ترکیب، زمان فکر، داده ها) را هدف قرار دهید.
ابزار (k6/JMeter/Locust) را انتخاب کنید، داشبورد RED را بالا ببرید.
آماده ایستاده و داده های دانه، غیر فعال کردن محدودیت های شخص ثالث/captchas.

8-20 روز

سناریوهای ساخت: مدل باز (نرخ ورود)، سرد/گرم/کش گرم.
بار اجرا → استرس → سنبله ؛ رفع نقطه زانو و تنگناها.
پیاده سازی دروازه های عملکرد در CI (میکرو اجرا).

21-30 روز

تست خیس 4-24 ساعت: نشت GC/رانش، تثبیت کننده.
محدودیت های سند، برنامه ظرفیت، تصاویر «RPS → p95/oshibki».
آماده runbook «چگونه برای افزایش محدودیت/مقیاس» و «چگونه به تنزل».

17) معیارهای بلوغ

پروفایل های واقع گرایانه (ترکیب، زمان تفکر، داده ها) وجود دارد که ≥ 80٪ از ترافیک را پوشش می دهد.
داشبورد قرمز + ردیابی برای همه آزمایشات متصل است.
دروازه های عملکرد هنگام بازگرداندن خطاهای p95/منتشر می شوند.
ظرفیت و نقطه زانو توسط خدمات کلیدی مستند شده است.
خیساندن ماهانه/استرس اجرا می شود و گزارش پیشرفت.
مقاومت در برابر «سنبله» توسط مقیاس خودکار و عدم وجود شکست آبشار تأیید می شود.

18) نتیجه گیری

تست بار یک عمل مهندسی منظم است، نه یک اندازه گیری یک بار. "مدل کاربران واقعی (مدل باز)، اندازه گیری آنچه نشان دهنده تجربه مشتری (SLI/SLO)، حفظ قابلیت مشاهده و دروازه در CI/CD، انجام استرس/سنبله/خیس کردن اجرا می شود و نقطه زانو را ثابت می کند. سپس رویدادهای پیک و قوهای سیاه به سناریوهای قابل کنترل تبدیل می شوند و عملکرد به یک پارامتر قابل پیش بینی و قابل اندازه گیری از پلت فرم شما تبدیل می شود.