تست عملکرد

انتخاب ابزار تست عملکرد؛ از Workload Model تا Generator

انتشار در تاریخ توسط محمد عسکری

سه Candidate فرضی یک سرویس با ظرفیت ۱۰۰ درخواست‌برثانیه را «تست» کردند. Dashboard اول P95=۴.83s و backlog=۵۰۹ نشان داد؛ دومی و سومی P95=100ms و ظاهراً وضعیت سالم. تفاوت از ابزار سریع‌تر نبود: فقط اولی تمام بار هدف ۱۵۰ RPS را تحویل داده بود. Closed-loop با کندشدن سیستم خودبه‌خود به ۱۰۰ RPS افتاد و Generator اشباع‌شده فقط ۸۰ RPS فرستاد.

انتخاب ابزار تست عملکرد با تعداد نمودار، Virtual User ادعایی یا رکورد یک Demo انجام نمی‌شود. ابزار باید Workload contract را با Protocol و Connection semantics درست تولید کند، Load تحویلی و Dropped work را حسابرسی کند، خودش Bottleneck نشود، Response را از نظر کسب‌وکاری Validate کند و Generator/SUT/Dependency evidence را روی یک Timeline قابل‌تکرار جمع کند.

این راهنما رتبه‌بندی JMeter، k6، Gatling، Locust یا محصول تجاری نیست. قابلیت، قیمت، Cloud region، License و Version تغییر می‌کنند. ما یک Qualification Lab می‌سازیم تا Candidateها را با Script، Data، Generator budget، Failure injection، Telemetry، CI و Exit یکسان بسنجید.

پاسخ کوتاه: بهترین ابزار تست عملکرد چیست؟

بهترین ابزار، گزینه‌ای است که بار درست را به اندازه درست تولید کند و ثابت کند همان بار را تولید کرده است. سپس باید Latency/Error/Throughput/Backlog/Resource/Correctness را با Timestamp و Run identity مشترک ثبت کند. اگر ابزار 100ms گزارش کند اما فقط نیمی از Arrivalهای هدف را فرستاده باشد، نتیجه برای Capacity decision معتبر نیست.

انتخاب ممکن است یک Stack باشد، نه یک محصول: Protocol-level generator برای بار حجیم، Browser runner کوچک برای تجربه Client، Observability برای Root cause و Notebook/Report برای تحلیل. Feature «Dashboard داخلی» نباید شما را مجبور کند Generator ضعیف یا Protocol اشتباه انتخاب کنید.

مرز این مقاله با سایر راهنماها

راهنمای تست عملکرد مفاهیم Load/Stress/Spike/Soak و KPI پایه را توضیح می‌دهد. راهنمای Performance Test Plan مالک Workload model، SLO و طرح اجراست. مقایسه JMeter، k6 و Gatling برای شناخت گزینه‌هاست. مقاله حاضر مالک Qualification است: آیا Candidate می‌تواند Workload ازپیش‌تعریف‌شده را با Fidelity، ظرفیت Generator و Evidence قابل‌اعتماد اجرا کند؟

برای Hard gate عمومی Vendor، امنیت تأمین‌کننده، TCO، قرارداد و خروج از چارچوب انتخاب ابزار مدیریت تست استفاده کنید؛ اینجا معیارهای تخصصی Performance را به آن اضافه می‌کنیم.

قبل از ابزار، نقش‌های Performance Stack را تفکیک کنید

نقش پرسش Artifact
Workload generator چه Arrival/Concurrency و Protocolی تولید شد؟ Schedule، sent/dropped، generator telemetry
Functional validator Response فقط سریع بود یا درست هم بود؟ Check/Oracle و error class
Browser/mobile probe کاربر چه Render/Interactionی دید؟ Client timing، trace، frame/network
Observability زمان کجا مصرف شد؟ Metric/log/trace/profile
Orchestrator Agent/Data/Version چگونه هماهنگ شدند؟ Run manifest و node inventory
Analysis/report آیا Gate و عدم‌قطعیت قابل توضیح است؟ Dataset، query، decision record

Browser برای هزاران Session پرهزینه و Protocol generator برای Core Web Vitals ناکافی است. Tool sprawl هم هزینه دارد؛ مرز هر نقش، System of Record و Join key را بنویسید.

Problem Brief و Decision را تعریف کنید

یک صفحه شامل این موارد کافی است:

  1. Decision: Release gate، Capacity، Architecture comparison یا incident reproduction؛
  2. SUT boundary: Client، CDN، Gateway، Service، Queue، DB و Third party؛
  3. Protocol: HTTP/۱.۱، HTTP/۲، HTTP/۳، WebSocket، SSE، gRPC یا Messaging؛
  4. Workload: Open arrival، Closed concurrency، mix، burst، think time و duration؛
  5. Data/state: unique/shared، read/write، cleanup و cache state؛
  6. SLO/gates: tail latency، valid throughput، error، correctness، backlog و recovery؛
  7. Scale: target، headroom و geographic source؛
  8. Environment: Production-like چه معنی دارد و چه تفاوتی باقی است؛
  9. Evidence: raw result، generator/SUT telemetry، manifest و owner؛
  10. Constraints: security، network، budget، CI time و access.

هدف مبهم «۱۰۰۰ کاربر» کافی نیست. آیا ۱۰۰۰ کاربر هم‌زمان Active هستند، ۱۰۰۰ Session ثبت‌شده‌اند، ۱۰۰۰ Arrival در دقیقه داریم یا ۱۰۰۰ Connection باز؟ Candidate باید Unit و Scheduling semantics را صریح کند.

Workload Contract را Freeze کنید

run_id: perf-checkout-2026-08-12-01
model: open-arrival
target: 150 checkout-start/s for 10m
mix: browse 70%, cart 20%, checkout 8%, payment-status 2%
burst: 2x for 20s at minute 6
data: unique customer/order/idempotency key per iteration
connection: HTTP/2, TLS reuse enabled, max streams documented
gate: delivered arrivals >= 99%; dropped = 0
gate: valid checkout p95 < 800ms; p99 < 1500ms
gate: business errors < 0.5%; duplicate order = 0
recovery: backlog drained within 120s
evidence: generator + gateway + app + db + queue + ledger

Candidate حق ندارد برای سبزشدن، Model، mix، Connection reuse، validation یا graceful stop را بی‌صدا تغییر دهد. هر Override باید در Manifest و Report دیده شود.

Hard Gateهای تخصصی ابزار Performance

  • Protocol/Version/Authentication/Streaming واقعی SUT؛
  • Open یا Closed scheduling موردنیاز با Metric بار تحویلی؛
  • ثبت scheduled/sent/completed/dropped/cancelled؛
  • Generator telemetry و Schedule lag قابل Export؛
  • Correlation، Parameterization و Unique data بدون Hotspot مصنوعی؛
  • Response validation و Custom business metrics؛
  • CLI/headless، Exit code، Threshold و CI؛
  • Distributed execution با Node version/config/data قابل حسابرسی؛
  • Raw result با Timestamp/Tag/Error class و Run ID؛
  • Integration با Metric/log/trace و Clock sync؛
  • Secret/TLS/private-network controls؛
  • Capacity و TCO برای مقیاس هدف با Headroom؛
  • Full export و بازاجرای مستقل Script/Data/Result.

Protocol support را با تیک Feature نسنجید

«HTTP/۲ supported» باید به سؤال‌های دقیق تبدیل شود: آیا ALPN واقعاً Version ۲ را Negotiation کرده؟ چند Connection و Stream هم‌زمان داریم؟ Header compression، flow control، reset، push/deprecation و proxy path چگونه رفتار می‌کنند؟ RFC 9113 نشان می‌دهد HTTP/۲ چند Stream مستقل را روی یک Connection multiplex می‌کند؛ ابزار HTTP/۱.۱ با Connection pool متفاوت می‌تواند SUT دیگری را آزمایش کند.

Protocol Qualification Matrix

لایه Test لازم Evidence
DNS/TCP/TLS reuse، handshake، certificate، proxy connection timing و packet/trace sample
HTTP version، redirect، cookie، compression، cache negotiated protocol و request dump محدود
HTTP/2/3 stream/multiplex/reset/limit connection-stream counters
WebSocket/SSE long-lived، message rate، reconnect open connections و message lag/loss
gRPC unary/stream، status/trailer/deadline RPC method/status/message count
Messaging producer/consumer/ack/key/order publish rate، lag، duplicate/loss

برای جزئیات Unary/Streaming/Deadline و Protobuf، راهنمای تست gRPC را بخوانید. Wrapper سفارشی ممکن است Protocol را اجرا کند اما Timing یا Error semantics ناقص داشته باشد؛ Contract test لازم است.

Open و Closed model را با Production semantics تطبیق دهید

در Closed model، تعداد User/Iteration فعال ثابت است و هر User معمولاً پس از پایان پاسخ، کار بعدی را شروع می‌کند. با کندشدن SUT، نرخ Arrival افت می‌کند. در Open model، Arrival مستقل از زمان پاسخ Schedule می‌شود؛ کندی می‌تواند Queue/Concurrency را بالا ببرد.

مستند Scenario concepts در k6 تفاوت Open/Closed و Dropped iteration را صریح می‌کند. مستند Injection در Gatling نیز API جدا برای نرخ User ورودی و User هم‌زمان دارد. این‌ها ادعای برتری نیستند؛ معیار شفافیت Scheduling semantics هستند.

کدام Model برای کدام رفتار؟

  • کاربر Interactive با Think time و Session محدود: Closed می‌تواند مناسب باشد؛
  • Webhook، API عمومی، Arrival پرداخت یا Queue producer: اغلب Open؛
  • Connection pool یا Concurrent job limit: Closed برای Capacity همان منبع؛
  • ترکیب Browse/Checkout/Callback: چند Scenario با Modelهای جدا؛
  • اگر مطمئن نیستید، Production arrival/concurrency/queue داده را بررسی کنید.

تغییر Model برای مقایسه Candidate ممنوع است. Closed test با P95 پایین پاسخ Open-arrival capacity را نمی‌دهد.

بار هدف، بار Scheduleشده و بار تحویلی سه عددند

حداقل این Counterها را بخواهید:

  • Target: Contract چه می‌خواست؛
  • Scheduled: Scheduler چند Iteration برنامه‌ریزی کرد؛
  • Started/Sent: چند Request واقعاً شروع شد؛
  • Completed: چند مورد تا Deadline یا Graceful stop تمام شد؛
  • Dropped/Missed: چند Arrival به‌علت کمبود VU/CPU/queue شروع نشد؛
  • Cancelled/Interrupted: چند کار هنگام Stop قطع شد؛
  • Valid: چند Response از Oracle کسب‌وکاری عبور کرد.
delivery_ratio = sent / scheduled
valid_goodput = business_valid_completed / second
backlog_at_deadline = sent - completed_by_deadline
schedule_lag = actual_start_time - planned_start_time

Gate فقط روی Response time کافی نیست. Delivery ratio پایین باید Run را Invalid یا Fail کند، حتی اگر SUT latency عالی باشد.

Generator را پیش از SUT کالیبره کنید

یک Endpoint محلی/Stub سریع و قابل‌کنترل بسازید تا سقف خود Generator را بسنجید. با همان Script complexity، validation، TLS، payload، logging و output، نرخ را مرحله‌ای بالا ببرید و این موارد را ثبت کنید:

  • CPU per core، memory/GC/event-loop و thread count؛
  • NIC bandwidth، packet/drop/retransmit و ephemeral port؛
  • Schedule lag P50/P95/P99 و dropped work؛
  • Connection/socket/TLS handshake و reuse؛
  • Result serialization/export backpressure؛
  • Clock drift و NTP status؛
  • Max stable rate با حداقل ۳۰٪ Headroom.

Best Practices رسمی JMeter تصریح می‌کند Hardware و Test plan روی تعداد Thread مؤثرند، کمبود Thread می‌تواند Coordinated Omission بسازد و برای بار واقعی باید Resource usage را کاهش داد. این اصل ابزارمحور نیست: Generator بخشی از سیستم اندازه‌گیری است.

Generator را روی SUT اجرا نکنید

هم‌مکانی CPU/Memory/Network contention می‌سازد و نتیجه را آلوده می‌کند. اگر برای Smoke کوچک ناچارید، محدودیت را ثبت و از آن Capacity conclusion نگیرید.

GUI برای ساخت، CLI برای بار واقعی

Editor و Live graph می‌توانند خود Generator را مصرف کنند. راهنمای رسمی Getting Started در JMeter ساخت/Debug را در GUI و اجرای Load را در CLI توصیه می‌کند. در هر Candidate، Script یکسان را Headless اجرا و تفاوت نرخ/CPU/Memory را اندازه بگیرید.

آموزش JMeter برای شروع عملی مناسب است، اما Qualification باید فراتر از ساخت اولین Thread Group برود: Recorder cleanup، correlation، data، check، CLI، distributed calibration و raw evidence.

Coordinated Omission را آگاهانه مدیریت کنید

وقتی Generator به‌علت کندی SUT Request بعدی را دیرتر می‌فرستد، زمان‌هایی که کاربر باید منتظر می‌ماند اما Sampleای ثبت نمی‌شود از Histogram حذف می‌شوند. نتیجه Tail latency خوش‌بینانه است. Open arrival یا اصلاح Histogram می‌تواند بخشی از این Blind spot را آشکار کند، اما باید Model Production را حفظ کند.

API رسمی HdrHistogram روش‌های ثبت/اصلاح با Expected interval را مستند می‌کند. Correction جادویی نیست: Expected interval، Pause source و raw samples را گزارش کنید و هم نمودار خام و هم corrected را نگه دارید.

Correlation و Parameterization را با State واقعی تست کنید

Recorder معمولاً Token/Session/ID را Capture می‌کند، نه Business dependency را. Candidate باید بتواند CSRF، OAuth token، order ID، cursor، correlation ID و dynamic URL را از Response استخراج، Validate، Transform و در Step بعد مصرف کند. Failure استخراج باید Error مستقل باشد، نه Request بعدی با مقدار خالی.

Data contract

  • هر Virtual user یا Iteration چه داده یکتایی می‌گیرد؟
  • Shard بین Nodeها overlap دارد یا نه؟
  • Read/write ratio و Hot-key distribution نماینده‌اند؟
  • Setup خارج از Timed transaction است؟
  • Cleanup/Reconciliation پس از Abort انجام می‌شود؟
  • Secret و PII در Script/Result/Log Mask می‌شوند؟
  • Dataset version و checksum در Manifest ثبت است؟

یک CSV مشترک روی چند Worker می‌تواند همه Nodeها را با همان Account شروع کند و Lock/Cache مصنوعی بسازد. برای Pipelineهای تحلیلی، File count، Cardinality، Skew و Mutation به اندازه حجم مهم‌اند؛ راهنمای تست عملکرد Big Data Data-shape contract را عمیق‌تر توضیح می‌دهد.

Response سریع اما غلط را Success حساب نکنید

HTTP ۲۰۰ ممکن است Error payload، stale cache، partial result یا duplicate operation باشد. Checkها را Risk-based طراحی کنید:

  • Status و Content-type؛
  • Schema و فیلدهای بحرانی؛
  • Business invariant و مقدار Canonical؛
  • Uniqueness/Idempotency؛
  • عدم وجود Error marker در Body؛
  • Side effect در Queue/DB/Ledger برای Sample کنترل؛
  • Freshness/version و عدم پاسخ Cache نامعتبر؛
  • Size/row/message count در محدوده.

Validation سنگین می‌تواند Generator را اشباع کند. Check سبک را روی همه Responseها و Oracle عمیق را روی Sample مستقل اجرا کنید؛ نرخ Sample و Failure را گزارش کنید. Valid goodput از raw throughput مهم‌تر است.

Browser load و Protocol load را ترکیب نکنید

Protocol-level test برای Capacity backend با هزینه کمتر مناسب است؛ Browser test Render، JavaScript، Core Web Vitals و third-party resource را می‌بیند. الگوی رایج:

  • بار اصلی با Protocol generator؛
  • تعداد کم Browser probe هم‌زمان برای Client experience؛
  • RUM/field data برای اعتبارسنجی Lab؛
  • Correlation ID مشترک برای Join کردن Journey.

هزار Browser ممکن است Generator farm را تست کند، نه SUT. از سوی دیگر، API latency پایین اثبات نمی‌کند صفحه قابل‌تعامل است. ابزار باید مرز Measurement را صریح کند.

Latency را به Stopwatchهای قابل‌مقایسه بشکنید

  • Schedule lag؛
  • DNS؛
  • TCP connect؛
  • TLS handshake؛
  • Request send/queue؛
  • TTFB/server wait؛
  • Response download؛
  • Client parse/render/action؛
  • Business completion/freshness.

Candidateها ممکن است «response time» را از نقطه‌های متفاوت اندازه بگیرند یا DNS/TLS را فقط در Connection اول ببینند. یک Echo/Delay endpoint با زمان معلوم بسازید و Stopwatch boundary را کالیبره کنید.

Semantic conventions متریک HTTP در OpenTelemetry برای Duration، method، server، status، error و negotiated protocol نام‌های مشترک پیشنهاد می‌کند. Tagها را به Route کم‌کاردینال محدود کنید؛ URL/ID خام می‌تواند Cardinality و Privacy را خراب کند.

Distributed load فقط افزودن Worker نیست

برای هر Node، Version ابزار/runtime/plugin/OS، CPU/memory/NIC، Region/AZ، clock offset، script hash، config hash، data shard و start/stop را ثبت کنید. Controller، result aggregator یا network link می‌تواند Bottleneck شود.

مستند Remote Testing در JMeter هشدار می‌دهد هر Server کل Test plan را اجرا می‌کند، Data fileها خودکار ارسال نمی‌شوند و Client/Network ممکن است اشباع شوند. مستند Distributed load در Locust نیز نقش Master/Worker و اجرای Userها روی Worker را روشن می‌کند. در هر معماری، Load split را از Result استنتاج نکنید؛ per-node Counter بخواهید.

Clock و aggregation

Offset کوچک میان Generator، Gateway، App و DB، Spike و Root cause را جابه‌جا می‌کند. NTP status/offset را قبل و بعد Run ذخیره کنید. Histogramهای Aggregated باید با روش درست Merge شوند؛ Average of averages و میانگین P95ها معتبر نیست.

Geographic load را با سؤال Network جدا کنید

برای Capacity داخلی، Generator نزدیک SUT اثر Internet را کم می‌کند. برای تجربه Region، Generator دور، DNS/CDN/TLS/peering را هم وارد Measurement می‌کند. این دو Run پاسخ متفاوت می‌دهند؛ آن‌ها را با یک SLO و یک Label مخلوط نکنید.

در ایران، مسیر ISP، اپراتور، دیتاسنتر داخلی/خارجی، فیلترینگ/اختلال، DNS، TLS و محدودیت Vendor cloud می‌تواند Result را تغییر دهد. Region label واقعی، ASN/ISP در صورت مجازبودن، packet loss و traceroute محدود را ثبت کنید. از یک Cloud region خارجی به‌عنوان نماینده همه کاربران ایرانی نتیجه نگیرید.

آزمایش اجرایی مدل بار و ظرفیت Generator

یک شبیه‌سازی قطعی با Node.js ۲۴.۱۸.۰ ساختیم. SUT فرضی ده Worker دارد و هر Request دقیقاً 100ms Service time می‌گیرد؛ ظرفیت نظری آن ۱۰۰ RPS است. Contract، ۱۵۰ RPS برای ۱۰ ثانیه یا ۱۵۰۰ Arrival است.

سه Runner فرضی‌اند: Open-loop همه Arrivalها را Schedule می‌کند؛ Closed-loop ده VU دارد و هر VU بعد از پاسخ Request بعدی را می‌فرستد؛ Runner سوم Open است اما Generator فقط ۸۰ RPS ظرفیت دارد. Network، retry، GC و خطای واقعی مدل نشده‌اند؛ هدف آموزش Qualification است، نه Benchmark ابزار.

const durationMs = 10_000
const targetRps = 150
const workers = 10
const serviceTimeMs = 100

// open: arrival مستقل از latency؛ هر arrival به اولین worker آزاد می‌رود
function runOpen(rate) {
  const sent = (durationMs * rate) / 1000
  // صف قطعی روی pool ده‌تایی شبیه‌سازی و finish/latency ثبت می‌شود
  return simulateQueue({ sent, rate, workers, serviceTimeMs })
}

// closed: ده VU پس از completion دوباره درخواست می‌فرستند
const closedSent = (durationMs / serviceTimeMs) * workers

const results = [
  runOpen(150),
  { model: "closed_10_vus", sent: closedSent },
  runOpen(80),
]

خروجی واقعی

model scheduled sent completed_by_10s backlog delivery p95_ms
open_150_rps 1500 1500 991 509 100.0% 4833.3
closed_10_vus 1500 1000 1000 0 66.7% 100.0
open_generator_capped_80_rps 1500 800 793 7 53.3% 100.0
naive_latency_winner=open_generator_capped_80_rps
valid_150_rps_delivery=open_150_rps

تفسیر و محدودیت

اگر فقط P95 را مقایسه کنیم، Generator محدود برنده است؛ چون کمترین بار را تحویل داده. Closed-loop هم با کندی SUT Arrival را به ۱۰۰ RPS محدود کرده است. فقط Open-loop Contract ۱۵۰ RPS را تحویل داده و overload را با Queue و Tail آشکار کرده است.

عددهای این مدل Prediction برای Production نیستند. Server queue واقعی، Scheduler، network، cache، retry و service-time distribution پیچیده‌اند. درس قابل‌انتقال: Report بدون Target/Scheduled/Sent/Dropped/Backlog و Generator telemetry صلاحیت Capacity decision ندارد.

PoC دو هفته‌ای ابزار تست عملکرد

  1. Workload contract، Expected counters و Gate را Freeze کنید.
  2. سه Endpoint ساده برای delay/error/payload و یک Journey واقعی انتخاب کنید.
  3. Protocol negotiation، connection reuse و authentication را Capture کنید.
  4. Correlation، unique data، cleanup و business checks را بسازید.
  5. Stopwatch را با delay معلوم کالیبره کنید.
  6. Generator سقف را روی Stub مرحله‌ای بسنجید.
  7. Open/Closed workload را جدا اجرا و Counterها را Reconcile کنید.
  8. CPU، memory، network، GC/event loop و schedule lag Generator را جمع کنید.
  9. یک Node را اشباع/قطع و رفتار Controller/Result را بررسی کنید.
  10. Data shard و total load را per-node جمع بزنید.
  11. SUT را overload و recovery/backlog drain را مشاهده کنید.
  12. Response سریع اما غلط و HTTP ۲۰۰ error body تزریق کنید.
  13. CI exit code، threshold، artifact و secret injection را اجرا کنید.
  14. Raw export، independent analysis و بازاجرای Script را تمرین کنید.

Evidence bundle هر Run

  • Run ID، purpose، owner و decision؛
  • Git commit/script/config/data checksum؛
  • Tool/runtime/plugin/container image؛
  • Workload model، mix، stages، duration، graceful stop؛
  • Node/region/clock/resource inventory؛
  • Target/scheduled/sent/completed/dropped/cancelled/valid؛
  • Latency raw/corrected boundaries و percentile؛
  • Error taxonomy و sample evidence؛
  • SUT/Dependency metric/log/trace links؛
  • Environment/deployment/config/data version؛
  • Cost و anomaly notes؛
  • Gate verdict، limitation و next action.

Observability integration را با Correlation اثبات کنید

Dashboard بازشدن Integration نیست. Run ID و Scenario/transaction tag باید از Generator به Gateway/App trace و Metric برسد، بدون اینکه Cardinality انفجاری یا PII بسازد. یک Request نمونه را End-to-End پیدا کنید و Aggregateهای Route/Status/Error را Reconcile کنید.

Telemetry خود SUT نیز Observer effect دارد. Sampling/Profiling level را ثابت، Overhead را اندازه و Runهای مقایسه‌ای را با Configuration یکسان اجرا کنید. فعال‌کردن Debug log فقط در Candidate شکست‌خورده مقایسه را ناعادلانه می‌کند.

Threshold و CI باید Run نامعتبر را هم Fail کنند

مستند Thresholdهای k6 نمونه Pass/Fail و Exit code غیرصفر را نشان می‌دهد. Gate خود را فقط روی latency/error نگذارید:

valid_run:
  delivery_ratio >= 0.99
  dropped_iterations == 0
  generator_cpu_p95 < 70%
  clock_offset_abs < 20ms
quality:
  valid_goodput >= target
  business_error_rate < 0.005
  p95_valid_checkout < 800ms
  duplicate_order == 0
recovery:
  backlog_drain < 120s

Run نامعتبر نباید Pass محصول باشد. برای Stage، Artifact، Cache و Ruleهای Pipeline از راهنمای GitLab CI استفاده کنید. PR Smoke کوچک، Nightly trend و Release/Capacity run مقیاس واقعی هدف‌های جدا دارند.

امنیت و مجوز تست بار

بار زیاد می‌تواند سرویس یا Third party را مختل کند. Scope، Target، زمان، سقف، Source IP، contact، abort condition، data، monitoring و recovery owner را کتبی تصویب کنید. Environment Production نیازمند مجوز صریح و Guardrail سخت‌تر است.

  • Credential/Token/PII در Script/Result mask شود؛
  • Generator node hardening و least privilege داشته باشد؛
  • Inbound/outbound firewall و Vendor agent کنترل شود؛
  • Certificate verification برای «حل مشکل» خاموش نشود؛
  • Rate/kill switch و on-call communication آزمایش شود؛
  • External provider/CDN/PSP بدون اجازه هدف بار نباشد؛
  • Artifact retention و access محدود باشد.

دسترسی و استقرار برای تیم ایرانی

Cloud load platform ممکن است از نظر Sign-up، پرداخت، Contract، Region، Agent download/update، support یا Network path پایدار نباشد. Legal/Procurement/Network باید وضعیت روز را با Account آزمایشی و سند رسمی Verify کنند؛ این متن مشاوره حقوقی نیست.

اگر Self-managed انتخاب می‌کنید، هزینه Container/Kubernetes/VM، Image registry، patch، certificate، secret، storage، observability و on-call را به TCO اضافه کنید. اگر Cloud است، Virtual-user/hour، data egress، static IP، private location، retention، team seat، advanced protocol و support tier را حساب کنید.

TCO تخصصی Performance Tool

TCO = license/cloud execution
    + generator compute and network
    + observability/storage/egress
    + scripting/correlation/data engineering
    + CI/platform administration
    + training/support/upgrades
    + failed-run investigation
    + migration and exit reserve

هزینه را به «Trusted decision» نسبت دهید، نه فقط Virtual-user-hour. Tool ارزان با Run نامعتبر، هزینه Incident یا Capacity overprovisioning را بالا می‌برد.

Exit و Portability را تمرین کنید

  • Script و shared library با Dependency lock؛
  • Config/Scenario/threshold؛
  • Dataset schema و generator؛
  • Raw sample/aggregate/error taxonomy؛
  • Dashboard/query/report؛
  • Run manifest/node inventory/cost؛
  • Plugin/extension source و build؛
  • Result/trace correlation IDs.

یک Scenario را در Harness دوم بازسازی و Target/Sent/Valid/P95 را با Tolerance ازپیش‌تعریف‌شده مقایسه کنید. Export PDF یا تصویر Chart، Portability نیست.

Scorecard پیشنهادی Qualification

پس از عبور Hard gateها، Weight را پیش از نتیجه Freeze کنید:

محور وزن Evidence
Workload fidelity ۱۸ Target/Scheduled/Sent/Model reconciliation
Protocol fidelity ۱۲ Negotiation/connection/stream/error contract
Generator capacity ۱۲ Stub calibration و ۳۰٪ headroom
Data/correlation/correctness ۱۰ Dynamic state و business Oracle
Distributed/geo execution ۸ Node/clock/data/load reconciliation
Telemetry/debug ۱۰ Run ID و end-to-end diagnosis
CI/governance ۸ Threshold/exit/artifact/review
Security/access ۷ Authorization/secret/network/region
TCO/operations ۸ Run mix و سه‌سال cost
Exit/portability ۷ Export/rebuild/replay

Rubric صفر تا پنج

  • ۰: Gate شکست‌خورده یا Counter حیاتی ناموجود؛
  • ۱: ادعای Vendor/Feature بدون اجرای Buyer؛
  • ۲: Happy path کوچک با Workaround؛
  • ۳: Workload نماینده با محدودیت مستند؛
  • ۴: Calibration/failure/distributed/CI evidence؛
  • ۵: تکرارپذیر، Governed، مقیاس هدف و Exit آزموده.

Score را کنار Confidence و Evidence ID نگه دارید. امتیاز ۴ از Trial پنج‌دقیقه‌ای هم‌ارز امتیاز ۴ از سه Run تکراری در Scale هدف نیست. Sensitivity را با وزن‌های «Reliability»، «Developer experience» و «Cost» اجرا کنید.

مثال کامل Checkout و PSP ایرانی

یک فروشگاه فرضی با Browse، Cart، Checkout، Redirect PSP، Callback و Status polling داریم. Workload Production نشان می‌دهد ۷۰٪ Browse، ۲۰٪ Cart، ۸٪ Checkout و ۲٪ Payment status است؛ Callback یک Open stream مستقل دارد.

Contract پیشنهادی

  • ۱۲۰ Browse/s، ۳۴ Cart/s، ۱۴ Checkout/s و ۴ Status/s؛
  • Burst دوبرابر Checkout برای ۲۰ ثانیه؛
  • Callback success/decline/duplicate/delayed/out-of-order؛
  • مبلغ Canonical ریال و نمایش تومان؛
  • رقم فارسی/عربی/لاتین و Unicode normalization؛
  • Idempotency key یکتا و Order/Payment/Ledger reconciliation؛
  • Timeout قبل و بعد از Commit؛
  • Tehran/UTC boundary؛
  • PSP Sandbox خارج از بار اصلی یا Stub قراردادی مجاز؛
  • Run ID در Gateway/App/Queue/DB trace.

آزمایش‌های ابزار روی همین مثال

  1. آیا Token/Order/Authority را Correlate می‌کند؟
  2. آیا هر Worker Data shard یکتا دارد؟
  3. آیا Callback مستقل از Latency Checkout Schedule می‌شود؟
  4. آیا HTTP/۲/TLS reuse با Production همسان است؟
  5. آیا Duplicate charge/order را حتی با HTTP ۲۰۰ می‌گیرد؟
  6. آیا Generator در Burst هنوز delivery≥۹۹٪ دارد؟
  7. آیا Queue lag و backlog drain روی Timeline است؟
  8. آیا Agent داخلی و Region خارجی Result جدا دارند؟
  9. آیا Abort، Orphan data را Reconcile می‌کند؟
  10. آیا Evidence بدون PAN/Token حساس Export می‌شود؟

Operating Model تیم

نقش مسئولیت
Performance engineer Workload، Script، Calibration و تحلیل
Developer/architect Protocol/Testability و Root cause
SRE/Platform Environment، telemetry، capacity و recovery
Data/DB Dataset، query، lock و cleanup
Security/Network Authorization، secret، source و kill switch
Business/Product Journey mix، valid outcome و SLO
Decision owner Gate، limitation و residual risk

ابزار نباید فقط دست Performance specialist قابل‌فهم باشد. Script/Manifest/Report باید Review شود؛ در عین حال ساده‌سازی برای Stakeholder نباید Target delivery و Generator saturation را از Summary حذف کند.

متریک‌های سالم برای ابزار و برنامه

  • Delivery ratio و dropped/missed schedule؛
  • Generator CPU/memory/network/GC/schedule lag؛
  • Valid goodput به‌تفکیک Transaction؛
  • Error taxonomy، نه فقط HTTP error؛
  • Raw/corrected P50/P90/P95/P99 و max با Sample count؛
  • Concurrency/connection/stream/backlog؛
  • Node skew و clock offset؛
  • Script change lead time و Review defects؛
  • Invalid run rate و علت؛
  • Time-to-diagnose و evidence completeness؛
  • Cost per valid million requests و cost per trusted decision؛
  • Export/replay success و version drift.

تعداد Virtual user قابل‌فروش و تعداد Testهای اجراشده Metric کیفیت نیست. ابزار سالم باید آشکار کند چه زمانی خودش به سقف رسیده است.

برنامه ۳۰ روزه انتخاب و Pilot

روز ۱ تا ۵: Contract و Gate

Decision، boundary، Protocol، Model، mix، Data، SLO، scale، authorization، access و Evidence را Freeze کنید. Candidateها را فقط پس از Gate عمومی وارد Lab کنید.

روز ۶ تا ۱۲: Script و Calibration

Delay/error/payload endpoint و Journey واقعی را بسازید. Stopwatch، Protocol، Connection، Correlation، Data و Oracle را Validate و Generator ceiling را مرحله‌ای اندازه بگیرید.

روز ۱۳ تا ۲۰: Scale و Failure

Open/Closed، target delivery، coordinated omission، distributed node، controller/agent failure، clock، geo path، SUT overload و recovery را اجرا کنید. Raw evidence را بدون Dashboard vendor نیز تحلیل کنید.

روز ۲۱ تا ۲۶: CI، Security و Exit

Threshold/exit code، artifact، secret rotation، authorization، audit، cost و full export/rebuild را تمرین کنید. یک Reviewer دوم Result را Reproduce کند.

روز ۲۷ تا ۳۰: تصمیم

Gate، Score، Confidence، Sensitivity، TCO، limitation و Residual risk را مرور کنید. خروجی می‌تواند Adopt، Stack چندابزاری، Extend Pilot یا Reject باشد.

۱۵ ضدالگوی انتخاب ابزار Performance

  1. انتخاب بر اساس بیشترین Virtual User ادعایی؛
  2. یکی‌گرفتن Concurrent user و Arrival rate؛
  3. مقایسه Open با Closed؛
  4. گزارش latency بدون delivery ratio؛
  5. نادیده‌گرفتن dropped iteration و schedule lag؛
  6. اجرای GUI در بار اصلی؛
  7. Generator روی SUT host؛
  8. HTTP ۲۰۰ به‌عنوان تنها Oracle؛
  9. Recorder بدون correlation/data cleanup؛
  10. CSV مشترک بدون shard در Workerها؛
  11. میانگین‌گیری از Percentileهای Node؛
  12. Dashboard بدون raw export؛
  13. Retry خودکار بدون حفظ Attempt؛
  14. بار روی Third party بدون مجوز؛
  15. محاسبه TCO فقط با License.

چک‌لیست نهایی انتخاب

  • □ Decision و SUT boundary روشن است.
  • □ Workload contract و Model Freeze شده‌اند.
  • □ Protocol/Connection semantics Verify شده‌اند.
  • □ Target/Scheduled/Sent/Completed/Dropped/Valid ثبت می‌شوند.
  • □ Stopwatch با Delay معلوم کالیبره شده است.
  • □ Generator ceiling و ۳۰٪ Headroom اندازه‌گیری شده‌اند.
  • □ CLI/headless و resource-light output استفاده می‌شود.
  • □ Coordinated omission بررسی شده است.
  • □ Correlation/Data shard/Cleanup درست‌اند.
  • □ Business correctness زیر بار Validate می‌شود.
  • □ Distributed load و Node totals Reconcile شده‌اند.
  • □ Clock/Region/Network label ثبت است.
  • □ Generator/SUT/Dependency evidence با Run ID Join می‌شود.
  • □ Invalid-run gate پیش از SLO gate اجرا می‌شود.
  • □ مجوز، kill switch، Secret و Artifact امن‌اند.
  • □ TCO با مقیاس واقعی محاسبه شده است.
  • □ Raw export/rebuild/replay آزموده شده است.
  • □ Score/Confidence/Sensitivity/Residual risk ثبت‌اند.

سؤالات متداول انتخاب ابزار تست عملکرد

JMeter بهتر است یا k6 یا Gatling؟

بدون Workload contract پاسخ معناداری ندارد. Protocol، Open/Closed model، مهارت تیم، CI، distributed scale، raw evidence، Generator capacity، TCO و Exit را روی Scenario خودتان بسنجید. مقایسه محصولی برای Shortlist است؛ PoC برای تصمیم.

چند Virtual User برای تست کافی است؟

Virtual user واحد Business load نیست. از Arrival rate، concurrency، session duration، think time و transaction mix Production شروع کنید. یک VU می‌تواند نرخ‌های بسیار متفاوت تولید کند؛ با کندشدن SUT نیز Closed VU نرخ را کاهش می‌دهد.

چرا ابزار latency خوب نشان می‌دهد اما Production کند است؟

ممکن است بار هدف تحویل نشده، Model غلط، Generator اشباع، Connection/cache متفاوت، Tail حذف‌شده، Data غیرنماینده، Third party Stub یا Oracle ناکافی باشد. Target/Sent/Dropped، Generator telemetry و Stopwatch boundary را نخست بررسی کنید.

آیا ابزار Cloud همیشه برای بار بزرگ بهتر است؟

Cloud می‌تواند Provisioning و Region را آسان کند، اما Network path، private connectivity، Region availability، egress، static IP، data/security، License و دسترسی تجاری مهم‌اند. Self-managed نیز هزینه عملیات و Calibration دارد. هر دو را با Scale/TCO واقعی بسنجید.

PoC ابزار تست عملکرد چقدر طول بکشد؟

برای Shortlist کوچک، دو هفته فنی به‌علاوه زمان Procurement/Security شروع معقولی است. شرط مهم‌تر، اجرای Protocol، Model، Calibration، Failure، distributed load، CI و Exit است؛ PoC یک Login پنج‌دقیقه‌ای حتی اگر سریع باشد Evidence کافی نمی‌دهد.

جمع‌بندی

ابزار Performance بخشی از Measurement system است؛ اگر Scheduler، Generator، Data یا Stopwatch خطا داشته باشد، نمودار زیبا تصمیم بد را دقیق‌تر نمایش می‌دهد. انتخاب درست با Workload contract و Hard gate شروع می‌شود، نه با نام Vendor.

آزمایش کنترل‌شده نشان داد Runner با P95=100ms می‌تواند فقط ۵۳٫۳٪ بار هدف را تحویل داده باشد؛ Runner دیگری با همان 100ms به‌دلیل Closed model فقط ۶۶٫۷٪ Arrival هدف را ساخته بود. پیش از اعتماد به latency، Target/Scheduled/Sent/Dropped/Valid، Generator headroom، Protocol، Data، Oracle و Evidence را اثبات کنید؛ بهترین ابزار همان است که وقتی قادر به اجرای آزمایش نیست، صادقانه Run را نامعتبر اعلام کند.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید