در تست عملکرد مستمر، خطر فقط کندبودن سیستم نیست؛ مقایسهٔ نامعتبر هم خطر است. Candidate ممکن است میانگین ۱۸۰ میلیثانیه، نرخ خطای ۰٫۵٪ و Gate سبز داشته باشد، اما Baseline روی Build، Environment، Workload، Data یا Telemetry دیگری اجرا شده باشد. در این حالت عدد دقیق است، ولی پاسخ پرسش Regression را نمیدهد.
این راهنما تست عملکرد را به چند Stage ثابت یا فهرست ابزار تبدیل نمیکند. یک Performance Evidence Ladder میسازد که از Question و Workload شروع میشود، Subject/Environment/Measurement را قفل میکند، Baseline و Candidate را فقط در شرایط قابلمقایسه میسنجد و نتیجه را با عدمقطعیت به Decision میرساند. هدف، بازخورد مناسب در زمان مناسب است؛ نه ادعای ظرفیت Production، رعایت SLO یا «عملکرد برتر» از یک Run آزمایشگاهی.
مسیر کوتاه: Performance feedback در هشت گام
| گام | پرسش | خروجی |
|---|---|---|
| Question | Regression، Budget، Capacity یا Diagnosis؟ | Claim boundary |
| Scenario | کدام journey/operation و success؟ | Scenario contract |
| Workload | Arrival، rate، mix، duration و state چیست؟ | Workload model |
| Subject | کدام Build/Artifact/config/data؟ | Immutable identity |
| Measure | Duration از کجا تا کجا و Error چیست؟ | Metric semantics |
| Compare | Baseline و Candidate قابلمقایسهاند؟ | Comparability verdict |
| Decide | Absolute/relative/tail/uncertainty rules چیست؟ | Regression decision |
| Learn | Production signal چه چیزی را اصلاح میکند؟ | Feedback/next experiment |
Continuous Performance Testing چیست؟
تست عملکرد مستمر یک Test type تازه نیست. روشی برای توزیع سؤالهای عملکردی در چرخهٔ تغییر است: بررسی سریع Algorithm یا component، مقایسهٔ API/service، آزمایش system/workload، و مشاهدهٔ محدود Production. هر لایه Fidelity، هزینه، سرعت و Claim متفاوت دارد. «مستمر» نیز لزوماً به معنی اجرای هر تست روی هر Commit نیست؛ Trigger باید متناسب با Risk، تغییر، هزینه و Feedback deadline باشد.
| سطح | سؤال مناسب | سرعت تقریبی | Claim ممنوع |
|---|---|---|---|
| Microbenchmark | پیادهسازی محلی کندتر شد؟ | سریع | Latency کاربر/Capacity |
| Component/API | Service در Workload کنترلشده Regression دارد؟ | میانه | End-to-end SLO |
| System | Journey و dependencyها زیر بار چگونهاند؟ | کندتر | Production equivalence |
| Capacity/Stress | کجا Saturation/Failure transition رخ میدهد؟ | پرخرج | ظرفیت قطعی آینده |
| Production observation | کاربر/traffic واقعی چه signalی دارد؟ | مداوم | آزمایش کنترلشده بدون confounder |
انواع Load، Stress، Spike، Endurance، Scalability و Capacity و طراحی پایهٔ آنها در راهنمای جامع تست عملکرد آمده است. این صفحه فقط اتصال لایهها به CI/CD و Comparability را مالک است.
مالکیت این مقاله: Performance Evidence Ladder
Risk / User Journey / Performance Question -> Scenario + Workload Contract -> Subject + Environment + Dataset -> Instrumentation + Metric Semantics -> Repeated Baseline and Candidate Runs -> Comparability Audit -> Absolute + Relative + Tail + Error + Resource Rules -> PASS | REGRESSION | REVIEW | INVALID -> Authorized Decision / Exception / Rerun -> Production Feedback / Model Revision
اول سؤال را مشخص کنید؛ یک Run پاسخ همهچیز نیست
| Question type | Baseline | خروجی | محدودیت |
|---|---|---|---|
| Regression | Build قبلی در Context همسان | Delta/uncertainty | نه SLO یا Capacity |
| Absolute budget | Requirement/Policy | within/outside budget | Requirement adequacy جداست |
| Capacity | Workload/scale model | saturation envelope | تقاضای آینده نامطمئن |
| Scalability | چند resource level | response curve | extrapolation محدود |
| Diagnosis | known symptom/run | hypotheses/evidence | Cause قطعی نیست |
| SLO validation | SLI/SLO spec و traffic scope | bounded evidence | آزمایشگاه جای production window نیست |
performanceQuestion: id: Q-CHECKOUT-LATENCY-17 type: REGRESSION subjectChange: C17 / B17 scenario: SCN-CHECKOUT-17 comparison: B16 vs B17 under same PERF contract primaryClaim: candidate p95 regression is within policy bound secondarySignals: p50, p99, business errors, throughput, saturation exclusions: production capacity, SLO compliance, user satisfaction decisionAudience: performance-risk-owner-a
Scenario فقط URL نیست
یک Scenario باید Actor، precondition، state، operation sequence، success oracle، error taxonomy، correlation، data lifecycle و cleanup داشته باشد. `POST /checkout` با status ۲۰۰ ممکن است business failure، duplicate order، reconciliation gap یا timeout پنهان داشته باشد. Latency موفق و ناموفق را کورکورانه مخلوط نکنید.
scenario: id: SCN-CHECKOUT-17 actor: customer-syn precondition: cart with 3 synthetic items steps: create-order -> start-attempt -> callback-stub -> confirm success: order-confirmed with same correlation ID and ledger balance errors: transport | timeout | http-5xx | business-reject | client-cancel data: DATA-PERF-17 cleanup: deterministic tenant reset exclusions: notification delivery, real PSP, production user
Workload Model: «۱۰۰ کاربر» کافی نیست
| بعد | پرسش | نمونه |
|---|---|---|
| Model | Open یا Closed؟ | open arrivals |
| Rate | درخواست/transaction در زمان؟ | 100 request/s |
| Concurrency | ورودی یا پیامد latency؟ | observed، نه fixed users |
| Mix | سهم هر Journey/role/data؟ | 70/20/10 |
| Ramp | بار چگونه تغییر میکند؟ | 2m linear |
| Warm-up | کدام Window حذف/گزارش میشود؟ | 5m excluded and retained |
| Steady window | چه مدت؟ | 15m |
| Think time | Distribution چیست؟ | SCN-v4 |
| Retry/timeout | چه کسی و چند بار؟ | generator off/service counted |
| State | Cache/pool/queue شروع؟ | controlled warm state |
در مدل Closed، کندشدن پاسخ میتواند نرخ درخواست را خودبهخود کم کند و overload واقعی را پنهان کند؛ در مدل Open، Generator باید rate را مستقل از response حفظ کند. هیچکدام همیشه بهتر نیستند. Workload باید رفتار موردسؤال را مدل کند و limitation آن صریح باشد.
Subject Contract: دقیقاً چه چیزی سنجیده شد؟
| هویت | نمونه | Mismatch رایج |
|---|---|---|
| Source/Build/Artifact | C17/B17/sha256:ART17 | `latest` یا rebuild |
| Config | CFG-PERF-7 | feature flag/pool متفاوت |
| Dependencies | DEP-SNAP-17 | shared service drift |
| Environment | ENV-PERF-7 | نام staging |
| Topology/resources | TOPO-7/RES-7 | CPU limit/replica متفاوت |
| Dataset | DATA-PERF-17 | حجم/cardinality/skew متفاوت |
| Workload | WL-v4 | script یا mix متفاوت |
| Generator | GEN-v3 | laptop یا image latest |
| Telemetry | TEL-v5/MET-v3 | instrumentation drift |
Environment برابر Production لازم نیست؛ Fidelity باید هدفدار باشد
محیط «دقیقاً مشابه Production» معمولاً ادعایی غیرقابلاثبات و پرهزینه است. برای Regression، ثبات و تقارن Baseline/Candidate ممکن است مهمتر از شباهت کامل باشد. برای Capacity، topology/resource/dependency fidelity اهمیت بیشتری دارد. برای user latency، network/client/cache/CDN fidelity مطرح است. Fidelity profile را بر اساس Question بسازید و Gapها را در Claim limit نگه دارید.
environmentProfile: id: ENV-PERF-7 purpose: controlled regression comparison topology: TOPO-7 resources: RES-7 config/flags: CFG-PERF-7 dependencies: local deterministic stubs + declared fidelity network: NET-PERF-2 dataset: DATA-PERF-17 isolation: tenant + namespace + quiet-window controls observability: TEL-v5 gaps: no CDN, no multi-region, no real PSP, smaller dataset cardinality claimLimit: laboratory regression only
برای طراحی محیط و Drift/Fidelity، معماری محیط تست مدرن مرجع مستقل است. Container و IaC تکرارپذیری را کمک میکنند، اما noisy neighbor، hypervisor، kernel، clock، network و dependency behavior را خودکار یکسان نمیکنند.
Data واقعی لازم نیست؛ توزیع و state باید نماینده باشد
کپی Production میتواند PII، Secret، retention و مجوز را نقض کند و بازتولیدپذیری را نیز خراب کند. Data مصنوعی وقتی schema، cardinality، skew، hot/cold distribution، relationship، lifecycle و edgeها را مدل میکند ممکن است مناسبتر باشد. «حجم زیاد» بدون distribution و query/selectivity معنا ندارد.
| بعد داده | ثبت لازم | اثر عملکردی |
|---|---|---|
| Cardinality | rows/entities/keys | index/cache/plan |
| Distribution | skew/hot sets | contention/cache hit |
| Relationships | fan-out/depth | join/serialization |
| State | new/aged/archived | query path/storage |
| Payload | size/encoding/RTL | network/parser/memory |
| Mutation | write/read ratio | locks/queues |
| Privacy | synthetic/masked controls | safe repeatability |
Generator نیز System Under Observation است
اگر Generator CPU=۹۸٪ دارد، connection pool پر است یا ۴۵۰ request را drop کرده، بار اعلامشده به System نرسیده است. Generator version/image، location/network، time sync، resource saturation، achieved rate، dropped/late requests، queue lag، connection behavior و coordinated-omission handling را ثبت کنید.
| Signal Generator | Gate نمونه | اگر نقض شد |
|---|---|---|
| Achieved/target rate | 98..102% | INVALID/REVIEW |
| Dropped requests | ۰ یا policy-bound | نتیجه ناقص |
| CPU throttling | none | scale generator |
| Clock drift | bounded | trace/latency نامعتبر |
| Network saturation | below bound | isolate/distribute |
| Internal queue lag | below interval | coordinated omission risk |
Duration را از کجا تا کجا میسنجید؟
نام `response_time` مبهم است: قبل از ارسال byte نخست تا header؟ تا body کامل؟ شامل DNS/TLS/queue/retry/redirect؟ Client و server ممکن است boundary متفاوت داشته باشند. OpenTelemetry HTTP metric semantic conventions برای duration نام، نوع Histogram، واحد ثانیه و attributeهای مشترک پیشنهاد میدهد؛ اما شما همچنان باید client/server و end boundary را روشن کنید.
metricContract: id: MET-HTTP-DUR-v3 name: http.client.request.duration unit: s instrument: Histogram start: before first request byte is sent end: after response body is fully read retry: each attempt measured; scenario outcome separately correlated attributes: method, route-template, status/error class, protocol, build cardinalityPolicy: no user/order/raw URL IDs buckets/schema: versioned and identical for comparison missing/overflow: reported, not dropped clock: monotonic duration source
Average دم latency را پنهان میکند
میانگین ۱۸۰ms میتواند در کنار p95=340ms و p99=610ms باشد. برای latency، distribution، count، errors و tail را نگه دارید. Median تجربهٔ معمول و percentile بالاتر دم را نشان میدهد، اما هیچ percentile واحدی کل شکل توزیع یا تجربهٔ همهٔ کاربران را نمایندگی نمیکند.
| آمار | کاربرد | دام |
|---|---|---|
| Mean | هزینهٔ کل/برخی مدلها | پنهانکردن tail |
| p50 | حالت معمول | نادیدهگرفتن کاربران کند |
| p95/p99 | Tail behavior | Sample/bucket/aggregation sensitivity |
| Max | بدترین مشاهده | outlier/window sensitivity |
| Histogram | شکل/aggregation | resolution/bucket interpolation |
| Apdex | threshold summary | threshold/value assumptions |
Percentileها را میانگین نگیرید
میانگین p95 دو Run یا دو Instance، p95 مجموع observations نیست. راهنمای رسمی Prometheus دربارهٔ Histogram و Summary صریحاً هشدار میدهد که averaging quantiles از Summary معنی آماری ندارد؛ Histogramهای سازگار را میتوان بر اساس bucket count جمع و سپس quantile را تخمین زد. حتی آنجا هم bucket width و interpolation uncertainty باقی است.
BAD: aggregate_p95 = average(run1.p95, run2.p95) BETTER: assert compatible metric semantics + bucket schema merge observation counts / histograms report total N, run-level distributions and pooled estimate retain run-to-run variation if incompatible: DO_NOT_COMPARE / rerun
Error rate مخرج و Taxonomy میخواهد
۰٫۵٪ از چه چیزی؟ Attempt، request، transaction یا unique journey؟ آیا timeout، client cancel، business reject، 4xx، 5xx، retry و incomplete response در مخرج/صورتاند؟ اگر retry موفق، failure نخست را پنهان کند، latency و reliability هر دو دستکاری میشوند. Request outcome و business outcome را جدا، اما با correlation نگه دارید.
| Outcome | Request layer | Scenario layer |
|---|---|---|
| Transport failure | ERROR | FAILED/RETRIED |
| Timeout | ERROR + duration bound | UNKNOWN/FAILED طبق oracle |
| HTTP 200 + reject | protocol success | business failure |
| HTTP 503 then retry 200 | دو attempt | success-with-retry + total latency |
| Client cancel | separate class | Context dependent |
| Duplicate confirmation | ممکن است ۲۰۰ باشد | integrity failure |
Throughput بدون Offered load و Success بیمعناست
Throughput باید achieved successful work در Window تعریفشده باشد و در کنار offered rate، attempts، rejected، timeout، retry و dropped generator reports بیاید. بالا رفتن throughput با افزایش failure یا کاهش payload/validation بهبود نیست. Concurrency نیز گاهی نتیجهٔ arrival rate×latency است، نه ورودی مستقل.
Resource utilization را با Saturation و Work وصل کنید
| Signal | چه میگوید؟ | چه نمیگوید؟ |
|---|---|---|
| CPU utilization | زمان مصرفشده در Context | headroom یا bottleneck قطعی |
| CPU throttling | limit pressure | تنها علت latency |
| Memory/RSS/heap | footprint/state | leak بدون trend/GC/context |
| Queue depth/age | waiting/saturation signal | Cause |
| Pool utilization | resource contention | بهینهبودن pool |
| GC pause | runtime stop signal | user impact بدون correlation |
| DB wait/lock | database contention | root cause نهایی |
Warm-up، Cache و JIT را پنهان نکنید
حذف Warm-up میتواند برای steady-state comparison منطقی باشد، اما باید Window حذفشده و دلیل آن گزارش شود. Startup/first-request نیز ممکن است Requirement مستقلی باشد. Cache prime، JIT compilation، connection pool، autoscaling، DNS/TLS و data page cache باید کنترل یا بهعنوان Factor آزمایش شوند؛ نه اینکه با Run تکراری نامرئی شوند.
تکرار Run و عدمقطعیت
یک Run نقطهای تحت noise میتواند مثبت یا منفی کاذب بسازد. تکرار، randomization/paired order، quiet window، raw distributions و run-level variation کمک میکنند. تعداد تکرار جهانی وجود ندارد؛ expected effect، variance، هزینه و Decision risk مهماند. اگر Runها اختلاف غیرقابلتوضیح دارند، نتیجه `REVIEW/INCONCLUSIVE` است، نه میانگینگیری برای سبزشدن.
| طراحی | مزیت | ریسک |
|---|---|---|
| Baseline سپس Candidate | ساده | time drift/order effect |
| Paired alternating B/C | کاهش drift | cache/carryover |
| Randomized order | کاهش bias ترتیب | operational complexity |
| Shared environment sequential | resource parity | state contamination |
| Parallel isolated | زمان کمتر | hardware/noisy-neighbor mismatch |
Comparability Contract: پیش از محاسبهٔ Delta
comparability: question/scenario: same version baseline/candidate: immutable B16 / B17 environment/topology/resources/config: same or modeled delta dependencies/dataset/state: same snapshots workload/arrival/mix/ramp/duration: same WL-v4 generator/version/location/capacity: same GEN-v3 telemetry/metric/buckets/unit/boundaries: same TEL-v5/MET-v3 warmup/cache/retry/timeout/connection: same policies interference/time window: bounded and reported raw evidence: available for every Run result: COMPARABLE | CONDITIONALLY_COMPARABLE | NOT_COMPARABLE mismatchDisposition: model | exception | rerun
Absolute و Relative Rule را با هم نگه دارید
| قاعده | مثال ساختگی | فایده | دام |
|---|---|---|---|
| Absolute | p95≤0.35s | Budget مستقل | Candidate بدتر ولی هنوز زیر سقف |
| Relative | p95 regression≤8% | حساس به تغییر | Baseline بد/نویز |
| Tail | p99≤0.65s | دم | Sample/resolution |
| Error | business error≤0.8% | جلوگیری از fast failure | Taxonomy/mخرج |
| Throughput | achieved≥98% offered | بار واقعی | generator saturation |
| Resource | no throttling/queue runaway | Saturation | fixed universal threshold |
| Uncertainty | run disagreement→REVIEW | ضد false precision | Review debt |
SLO، SLI و Test Threshold یکی نیستند
SLI تعریف indicator خدمت برای Population/Window/measurement مشخص است؛ SLO target آن indicator در یک Window و برای user/service scope است؛ Test threshold یک policy آزمایشگاهی برای Question محدود است. میتوان آنها را مرتبط کرد، اما برابرگرفتنشان بدون traffic، measurement point، error budget، exclusion و production context نادرست است.
| Artifact | Subject/Window | مثال | Authority |
|---|---|---|---|
| SLI | service population/time | good eligible requests / eligible | service measurement owner |
| SLO | production service/window | 99.9% over 28d | service/product governance |
| Test oracle | Run/Build/Scenario | p95≤0.35s | test policy |
| Regression rule | B16 vs B17 | delta≤8% | performance risk policy |
| Release decision | release/context | approve/defer | authorized role |
Fast feedback بدون تست همهچیز روی هر Commit
| Trigger | Suite | Budget | Claim |
|---|---|---|---|
| local/PR changed component | micro/component smoke | ثانیه/دقیقه | local regression signal |
| merge/main | API paired baseline | دقیقه | service comparison |
| nightly | broader workload matrix | دهها دقیقه | trend/interaction signal |
| release candidate | system/load/endurance slice | ساعت | bounded release evidence |
| scheduled capacity | stress/scale | پرخرج | capacity model update |
| canary/runtime | safe observation | traffic/window-bound | production context signal |
Change-based selection باید dependency graph و Risk را ببیند؛ docs-only و low-risk ممکن است Test نداشته باشند، اما applicability صریح لازم است. Scheduled suite نباید تنها محل کشف باشد؛ Result باید به Commit/Artifact و Owner برگردد.
نتیجهٔ Performance در Pipeline چه Outcomeهایی دارد؟
| Outcome | معنا | اقدام |
|---|---|---|
| PASS | قواعد روی Evidence قابلمقایسه برآورده شد | ورودی تصمیم بعدی |
| REGRESSION | قاعده نقض شد | diagnose/fix/decision |
| REVIEW | uncertainty یا اختلاف Run | بازبینی/تکرار |
| INVALID | generator/telemetry/evidence خراب | Run را استفاده نکنید |
| NOT_COMPARABLE | Baseline/Candidate mismatch | rerun/model/exception |
| NOT_APPLICABLE | طبق policy و change scope | rationale |
Pipeline نباید خودش ادعای «SLO met»، «capacity safe» یا Release approval بسازد. این خروجیها در گزارش وضعیت و تصمیم انتشار با سایر Evidence و Unknownها ترکیب میشوند.
آزمایش تکرارپذیر: میانگین ۱۸۰ms کافی است؟
Fixture ساختگی SYN-CONTINUOUS-PERFORMANCE-COMPARABILITY-01 Candidate با average=180ms و errorRate=۰.۵% دارد؛ Gate سطحیِ average<200ms/error<۱% نتیجهٔ `PASS` میدهد. ممیزی مستقل Question، Subject، Workload، Generator، Telemetry، Metric، aggregation، Rule و Evidence را بررسی میکند.
Fixture معیوب در برابر Contract
| بعد | Contract | Draft سبز |
|---|---|---|
| Question/Scenario | Q/SCN نسخهدار | خالی/checkout |
| Build | B16/B17 immutable | B15/B17-latest |
| Environment/Data | ENV7/DATA17 برابر | ENV5↔7/DATA-OLD↔17 |
| Workload | WL-v4 با arrival/rate/ramp | ۱۰۰-users و v2↔v4 |
| State | warmup/cache/retry/connection صریح | خالی/unknown/default |
| Generator | GEN-v3، ۴۱% CPU، zero drop | laptop/latest، ۹۸%، ۴۵۰ drop |
| Telemetry/Metric | TEL-v5/MET-v3/seconds/boundaries | v3↔v5/response_time/ms |
| Aggregation | merge compatible histograms | average of p95s |
| Gate/Evidence | absolute+relative+tail+uncertainty/raw | average only/screenshot |
خروجی Validator: ۴۴ Finding
fixture: SYN-CONTINUOUS-PERFORMANCE-COMPARABILITY-01 runtime: Node.js v26.7.0 superficial: PASS | avg=180ms | errorRate=0.5% auditedDraft: HOLD findings (44): 1 missing-or-wrong-performance-question 2 scenario-not-versioned 3 wrong-baseline-build 4 candidate-build-not-immutable 5 environment-not-versioned 6 baseline-candidate-environment-mismatch 7 dataset-unsafe-or-unversioned 8 baseline-candidate-dataset-mismatch 9 workload-not-versioned 10 baseline-candidate-workload-mismatch 11 arrival-model-missing 12 arrival-rate-missing 13 ramp-profile-missing 14 warmup-policy-missing 15 think-time-model-missing 16 retry-policy-implicit 17 cache-state-unknown 18 connection-reuse-unknown 19 generator-not-versioned 20 generator-version-unpinned 21 generator-saturated 22 generator-dropped-requests 23 telemetry-contract-missing 24 baseline-candidate-telemetry-mismatch 25 metric-semantics-unversioned 26 latency-start-boundary-missing 27 latency-end-boundary-missing 28 duration-unit-not-canonical-seconds 29 error-taxonomy-incomplete 30 business-success-rule-incomplete 31 percentiles-averaged-across-runs 32 resource-saturation-signal-missing 33 minimum-sample-rule-missing 34 tail-latency-rule-missing 35 absolute-budget-rule-missing 36 baseline-regression-rule-missing 37 uncertainty-policy-missing 38 pipeline-self-authorized-performance-claim 39 raw-measurements-missing 40 execution-manifest-missing 41 latency-distribution-evidence-missing 42 screenshot-only-evidence 43 test-result-overclaims-slo-and-capacity 44 incomparability-exception-or-rerun-missing corrected: READY_FOR_REGRESSION_REVIEW | findings=0
نسخهٔ اصلاحی چه کرد؟
نسخهٔ اصلاحی Q/SCN، B16/B17، ENV7، DATA17، WL-v4، GEN-v3، TEL-v5 و MET-v3 را قفل کرد؛ arrival=۱۰۰ request/s، ramp/warm-up/steady/think/retry/cache/connection را صریح کرد؛ Generator را unsaturated و zero-drop نگه داشت؛ سه Run ۹۰هزار observation برای هر Build با Histogramهای سازگار ساخت؛ p50/p95/p99، error، throughput و saturation را ثبت کرد؛ و absolute/relative/tail/error/uncertainty rule داد.
`READY_FOR_REGRESSION_REVIEW` تنها یعنی Contract ساختاری کامل است. صحت اندازهگیری، نمایندگی Workload، استقلال noise، رابطهٔ علّی تغییر، تحقق SLO، Capacity Production، تجربهٔ کاربر، صرفهجویی هزینه یا Release readiness را اثبات نمیکند. Reviewer باید Raw evidence و limitation را ببیند.
Lab فارسی و آفلاین Performance
Lab یک Checkout کاملاً ساختگی و بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation. بار فقط روی سرویسهای محلی با سقف resource و kill switch اجرا میشود. هیچ سایت، IP، شرکت، کاربر، پرداخت، بانک، PSP، Production یا سرویس ثالث هدف تست نیست.
| کنترل | قاعده |
|---|---|
| Identity | Tenant/Order/Attempt/Event/Ledger/Run/Build جدا |
| Money | IRR خیالی Canonical؛ تومان فقط View |
| Digits/RTL | فارسی/عربی/لاتین و Unicode/bidi |
| Time | UTC instant + Asia/Tehran؛ جلالی فقط Presentation |
| Data | synthetic، deterministic، بدون PII |
| Network | deny-all؛ local stub/registry/telemetry |
| Secrets | بدون PAN/CVV2/OTP/cookie/token/credential |
| Safety | rate ceiling/resource quota/abort trigger |
| Claim | بدون ادعای ظرفیت/بانکی/مالی/حقوقی/Production ایران |
Workload ساختگی Checkout
| Journey | Mix | Data state | Oracle |
|---|---|---|---|
| Create order | 45% | ۳ item synthetic | unique order/correlation |
| Start attempt | 25% | IRR amount view | one active attempt |
| Callback success | 15% | stub committed | confirmed + ledger |
| Duplicate callback | 5% | same event ID | idempotent |
| Timeout/retry | 5% | before/after fake commit | bounded final state |
| Reconciliation | 5% | late/reordered event | no unexplained delta |
Production: مشاهده، آزمایش امن و مرز اخلاقی
APM/RUM/Telemetry دادهٔ traffic واقعی میدهند، اما تغییر workload، release mix، network، geography، device و incident confounder دارند. Canary میتواند exposure را محدود کند، نه اینکه risk را صفر یا آزمایش را کنترلشده کند. Synthetic traffic، load یا failure injection در Production فقط با authorization، blast-radius، abort، privacy، on-call و rollback صریح مجاز است. راهنمای تست Shift-right امن این حوزه را جداگانه مالک است.
Telemetry مشترک Test و Production؛ Semantics یکسان، Context متفاوت
| بعد | Test | Production |
|---|---|---|
| Traffic | مدل کنترلشده | واقعی و متغیر |
| Build | Candidate/Baseline pinned | fleet/canary mix |
| Data | synthetic | حساس/واقعی |
| Metric semantics | MET-v3 | همان semantic contract مطلوب |
| Labels | run/scenario/build | service/version/region؛ بدون high-cardinality PII |
| Claim | bounded comparison | operational SLI observation |
| Feedback | Regression/diagnosis | SLO/model/incident/capacity |
AI/ML در تحلیل Performance: پیشنهاد، نه Verdict
مدل میتواند anomaly candidate، change point، cluster یا correlation پیشنهاد دهد؛ اما Drift، seasonality، multiple comparisons، label leakage و missing telemetry مثبت کاذب میسازند. Model/version/features/training window/threshold/output/reviewer را ثبت کنید. AI نباید Raw PII/Secret بگیرد، Cause قطعی بسازد یا Gate/Release را بیبررسی تصمیم دهد.
نقشها و حق تصمیم
| قابلیت | کار | مرز |
|---|---|---|
| Developer | instrument/change/diagnosis/remediation | Baseline را انتخاب گزینشی نکند |
| Performance specialist | model/measure/experiment/review | مالک انحصاری عملکرد نیست |
| Tester/QA | scenario/oracle/evidence/comparability | SLO/Release authority خودکار نیست |
| Platform/Ops | environment/telemetry/resource/runtime | Production ≠ test oracle قطعی |
| Product/Service owner | journey/impact/SLO context | عدد دلخواه بدون measurement contract ندهد |
| Risk/Release owner | تصمیم bounded | Regression evidence را تغییر ندهد |
متریکهای سلامت Capability و Countermetricها
| متریک | تعریف | Countermetric |
|---|---|---|
| Comparable run rate | comparable / eligible comparisons | scope narrowing |
| Invalid run rate | generator/telemetry invalid / runs | invalids hidden as pass |
| Feedback time | trigger→reviewable evidence distribution | skipped depth |
| Regression closure | retested fixed / eligible | foreign-build closure |
| Model drift | workload/fidelity deltas | constant churn |
| Tail evidence completeness | compatible distributions / required | huge metric cost |
| Exception debt | active/expired incomparability exceptions | automatic renewals |
| Production feedback linkage | model updates with source / updates | PII/high cardinality |
۳۰ ضدالگوی Continuous Performance Testing
- سرعت بازار بهعنوان ضرورت جهانی
- تست دیرهنگام همیشه شکستخورده
- همهٔ Performance tests روی هر Commit
- Stage ثابت برای هر سازمان
- فهرست ابزار محبوب بهجای سؤال
- ۱۰۰ user بدون arrival model
- Environment «دقیقاً Production»
- کپی Production بدون مجوز/توزیع
- Build/tag mutable
- Baseline قدیمی یا انتخاب گزینشی
- Workload/Data/Config متفاوت
- Generator laptop/latest
- Generator saturated و result سبز
- Dropped request پنهان
- response time بدون boundary
- ms/s mismatch
- Average تنها
- میانگین percentileها
- p95 بدون N/Histogram/schema
- Error rate بدون مخرج/taxonomy
- Fast failure بهعنوان بهبود latency
- Retry پنهان
- Warm-up حذفشده و گزارشنشده
- Cache/JIT/state ناشناخته
- یک Run بدون uncertainty
- Screenshot dashboard بهعنوان Evidence
- Threshold تست برابر SLO
- Pipeline برابر Release authority
- AI anomaly برابر Cause
- Test PASS برابر Capacity/SLO/کیفیت برتر
Pilot سیروزهٔ Performance Evidence Ladder
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | Question/journey/risk/authority | Claim boundary |
| روز ۴–۷ | Scenario/Workload/Data | versioned contracts |
| روز ۸–۱۱ | Environment/Generator/Telemetry | fidelity/gaps/safety |
| روز ۱۲–۱۵ | Metric/Error/Resource semantics | raw evidence schema |
| روز ۱۶–۲۰ | Repeated paired B/C runs | comparability verdict |
| روز ۲۱–۲۴ | Absolute/relative/tail/uncertainty policy | fixture-tested rules |
| روز ۲۵–۲۷ | CI trigger/report/owner | reviewable feedback |
| روز ۲۸–۳۰ | Production signal/model review | next gaps، no overclaim |
چکلیست Audit یک مقایسهٔ Performance
- Question/type/claim/audience/exclusions صریحاند.
- Scenario/actor/state/steps/success/error/correlation/cleanup نسخهدارند.
- Arrival model/rate/mix/ramp/warm-up/duration/think/retry/timeout ثبتاند.
- Baseline/Candidate Build/Artifact immutable و مربوطاند.
- Environment/topology/resource/config/dependency/data/state همسان یا delta مدلشده است.
- Generator/version/location/capacity/clock/achieved rate/drop معتبر است.
- Telemetry/instrument/version/metric/unit/start/end/buckets/labels ثابتاند.
- PII/Secret/high-cardinality label وارد telemetry نشده است.
- Error/business outcome/retry/timeout مخرج روشن دارند.
- Raw observations، manifest، histograms و resource signals موجودند.
- Average تنها نیست؛ count/distribution/p50/p95/p99/error گزارش شده است.
- Percentileها میانگین نشده و Histogram schema سازگار است.
- Runهای تکراری و variation/uncertainty حفظ شدهاند.
- Comparability پیش از Delta ارزیابی شده است.
- Absolute/relative/tail/error/throughput/resource/uncertainty rules نسخهدارند.
- INVALID/REVIEW/NOT_COMPARABLE به PASS نگاشته نشدهاند.
- Exception/Rerun scoped، owned و expiring است.
- Result از SLO/Capacity/Production/Release/quality claim فراتر نرفته است.
نقشهٔ مطالعهٔ مرتبط
برای انواع و طراحی Load/Stress/Endurance به مقالهٔ جامع ۷۲۷، برای orchestration عمومی CI/CD به Continuous Testing، برای محیط به ۱۷۶۱، برای Production به ۸۴۲، برای تست تابآوری و Recovery به تست تابآوری و برای سیستمهای آماری/غیرقطعی به Verdict آماری سیستم غیرقطعی مراجعه کنید.
پرسشهای متداول
آیا باید تست بار را روی هر Commit اجرا کنیم؟
خیر. Trigger باید با Risk، change scope، هزینه و feedback deadline سازگار باشد. Micro/component smoke ممکن است روی PR مناسب باشد؛ paired API comparison روی merge؛ workload matrix شبانه؛ و system/endurance/capacity روی زمانبندی یا Release candidate. Applicability و چیزی که اجرا نشده باید صریح بماند.
آیا p95 بهتر از Average است؟
برای دیدن Tail اغلب مفیدتر است، اما جای کل distribution، count، error و Context را نمیگیرد. p95 به Population، Window، sample size، bucket resolution و aggregation وابسته است. percentileهای Run/Instance را میانگین نگیرید؛ Histogramهای سازگار و variation هر Run را نگه دارید.
آیا محیط تست باید دقیقاً مثل Production باشد؟
نه همیشه و «دقیقاً» معمولاً قابلاثبات نیست. Fidelity را بر اساس Question انتخاب کنید. برای Regression، محیط ثابت و متقارن مهم است؛ برای Capacity، topology/resources؛ برای user latency، network/client/CDN. Gapها را ثبت و Claim را محدود کنید؛ Container/IaC بهتنهایی equivalence نمیسازند.
تفاوت Performance Test Threshold با SLO چیست؟
Test threshold قاعدهٔ یک Run/Build/Scenario آزمایشگاهی است. SLO هدف یک SLI برای service population و time window مشخص، معمولاً در Context عملیاتی است. میتوان Threshold را از SLO و بودجهٔ معماری مشتق کرد، اما Test PASS بهتنهایی SLO compliance یا error-budget health را ثابت نمیکند.
اگر Baseline و Candidate قابلمقایسه نباشند چه کنیم؟
نتیجه را `NOT_COMPARABLE` یا `REVIEW` کنید؛ تفاوت Environment/Data/Workload/Telemetry را مدل کنید یا هر دو Build را در Contract یکسان دوباره اجرا کنید. نسبتدادن Delta به کد، میانگینگیری یا Exception بیانقضا مناسب نیست. اگر mismatch ضروری است، Scope، uncertainty، owner و expiry آن ثبت شود.
جمعبندی: بازخورد سریع فقط با مقایسهٔ معتبر ارزش دارد
تست عملکرد در CI/CD وقتی به قابلیت تبدیل میشود که هر لایه سؤال و Claim محدود داشته باشد؛ Scenario/Workload/Build/Environment/Data/Generator/Telemetry ثابت و نسخهدار باشند؛ duration/error/throughput/resource معنا داشته باشند؛ Histogram و تکرار به جای Average تنها استفاده شود؛ Comparability قبل از Delta کنترل شود؛ و Gate عدمقطعیت را به REVIEW/INVALID تبدیل کند. این رویکرد میتواند بازخورد Regression را زودتر و قابلبازبینیتر کند، اما هزینه، SLO، ظرفیت Production، کیفیت یا Release را تضمین نمیکند.
