تست مقیاس‌پذیری؛ از Performance تا Capacity

یک سرویس با یک Replica در ۱۰۰ درخواست بر ثانیه، p95 برابر ۱۸۰ میلی‌ثانیه دارد. تیم منابع را چهار برابر می‌کند؛ Goodput به ۲۴۰ می‌رسد، اما p95 به ۹۴۰ میلی‌ثانیه و Error به ۷٪ می‌رسد. آیا سیستم «مقیاس‌پذیر» است چون Throughput بالا رفته؟ خیر؛ بدون منحنی Workload×Resource و معیار پذیرش، فقط یک عدد بزرگ‌تر دیده‌ایم. تفاوت تست عملکرد و تست مقیاس‌پذیری در همین نوع Claim است.

پاسخ کوتاه: Performance Testing رفتار سیستم را برای Workload، Configuration و Service-level مشخص اندازه می‌گیرد. Scalability Testing چند Configuration منبع را روی چند پله Workload مقایسه می‌کند تا Gain، Efficiency، Saturation، Capacity frontier، Bottleneck shift و Cost آشکار شوند. Scalability زیرمجموعه‌ای از ارزیابی Performance است، نه مترادف «بار بیشتر» یا «Autoscaling روشن».

تست عملکرد چیست؟

Performance Testing مشاهده رفتار زمانی، ظرفیت، مصرف منابع، خطا و درستی سیستم زیر یک Workload تعریف‌شده و در یک Configuration مشخص است. سؤال می‌تواند این باشد: «Build X با توپولوژی Y، برای Journey mix و Arrival rate مشخص، آیا p95/Error/Goodput/Correctness مورد انتظار را در Window تعیین‌شده برآورده می‌کند؟»

Performance فقط «سرعت» نیست. Time behavior، Throughput/Goodput، resource utilization، saturation، queue/backlog، error، timeout، correctness و recovery هم می‌توانند بخشی از Measurement contract باشند. برای طبقه‌بندی Load/Stress/Spike/Soak/Scalability به راهنمای تست عملکرد رجوع کنید.

تست مقیاس‌پذیری چیست؟

Scalability Testing نسبت تغییر Output مفید و Service level را به تغییر Workload و Resource بررسی می‌کند. یک نقطه کافی نیست؛ به Matrix و Curve نیاز داریم. باید بدانیم با افزایش CPU/Memory/Replica/Shard/Node یا تغییر Scale unit، Goodput چقدر رشد می‌کند، Efficiency چگونه افت می‌کند، کجا SLO می‌شکند و Bottleneck به کجا منتقل می‌شود.

Performance یک نقطه است؛ Scalability رابطه است

این جمله یک میان‌بُر مفید است، نه تعریف کامل. یک Performance run می‌تواند Curve بار بسازد، اما Scalability claim حداقل دو Resource configuration قابل‌مقایسه می‌خواهد. در محور افقی Workload، در محور دیگر Resource و در خروجی Latency/Goodput/Error/Cost را داریم. نتیجه یک سطح یا خانواده منحنی است.

جدول تفاوت Performance، Scalability، Capacity و Elasticity

مفهوم	سؤال	متغیر اصلی	Evidence
Performance	رفتار این Configuration زیر این Workload چیست؟	Workload/زمان/Build	Latency، Goodput، Error، Resource
Scalability	با تغییر Resource، Curve و Capacity چگونه عوض می‌شوند؟	Workload × Resource	Gain، Efficiency، frontier، bottleneck
Capacity	بیشترین بار قابل‌قبول برای یک Config طبق Criteria چیست؟	Service-level boundary	آخرین Cell که همه Criteria را پاس می‌کند
Elasticity	سیستم با تغییر تقاضا چه‌قدر درست و به‌موقع Scale می‌کند؟	زمان و Control loop	Detection/provision/readiness/settling/scale-in
Efficiency	Output مفید به ازای Resource/Cost چقدر است؟	Resource یا Cost	Goodput per unit و marginal gain

Scalability لزوماً رشد خطی نیست

دو برابرکردن منابع و انتظار Throughput دقیقاً دوبرابر، Ideal reference است؛ الزام جهانی نیست. Coordination، contention، serialization، partitioning، cache، network، storage، quota و dependency می‌توانند marginal gain را کم کنند. باید Target efficiency و Trade-off مختص سیستم تعیین شود، نه اینکه هر افت از خط ایده‌آل را Defect بنامیم.

Scale-up، Scale-out و Scale-diagonal

• Scale-up: CPU/Memory/IO یک Instance بیشتر می‌شود.
• Scale-out: Instance/Replica/Shard/Node اضافه می‌شود.
• Scale-diagonal: ابتدا اندازه Instance و سپس تعداد آن یا برعکس تغییر می‌کند.
• Scale-in/down: منابع کم می‌شوند؛ ایمنی drain و کارایی idle بررسی می‌شود.

مستند رسمی Azure درباره Scale-out Scalability را با نسبت Throughput gain به Resource increase توضیح می‌دهد و هشدار می‌دهد افزودن Instance درمان جادویی Bottleneck نیست. این راهنمای Cloud یک Universal benchmark نیست، ولی لنز Gain/Resource را روشن می‌کند.

Workload را با Concurrent users تعریف نکنید

هزار User می‌تواند یک request در ساعت یا صد request در ثانیه بسازد. Workload contract باید Open/Closed model، arrival rate یا concurrency، think time، Journey mix، read/write ratio، payload، data volume، key skew، burst و retry behavior داشته باشد. راهنمای Performance Test Plan این مدل را عمیق‌تر می‌کند.

Resource Configuration را دقیق Pin کنید

ResourceConfig {
  config_id, instance_type, replicas, nodes, zones,
  cpu_request_limit, memory_request_limit,
  storage_iops_throughput, network_bandwidth,
  database_tier, shards, connection_pool,
  quotas, topology_version, config_digest
}

«۴ سرور» بدون نوع Instance، limit/request، storage، network، zone و dependency config قابل‌مقایسه نیست. Resource واقعی مصرف‌شده و Resource provisioned را جدا نگه دارید؛ CPU limit دوبرابر با throttling می‌تواند رفتار دیگری از دو Core اختصاصی داشته باشد.

Scalability Matrix چگونه ساخته می‌شود؟

Cell	Resource	Offered load	Goodput	p95/Error	Verdict
C-1	R1	100	100	180ms / 0.1%	PASS
C-2	R2	200	180	260ms / 0.8%	PASS
C-3	R4	400	240	940ms / 7%	FAIL
C-4	R4	300	—	—	NOT_TESTED
C-5	R8	800	—	—	OUT_OF_SCOPE

Cellهای Missing و Invalid را حذف نکنید. اگر R4 فقط در بار ۴۰۰ Fail شده، Capacity واقعی آن را نمی‌دانیم؛ ممکن است بین ۲۰۰ و ۴۰۰ باشد. Interpolation و Extrapolation باید Policy و عدم‌قطعیت داشته باشند.

Workload stepها را چگونه انتخاب کنیم؟

Stepها باید ناحیه عادی، Target، Peak، Knee و Overload را با Resolution مناسب پوشش دهند. doubling سریع برای کشف محدوده مفید است، اما نزدیک Knee به Step کوچک‌تر نیاز داریم. Execution order را randomize/balance یا اثر warm cache/thermal/drift را ثبت کنید.

Offered Load، Admitted Load و Goodput

Offered load چیزی است که Generator تلاش می‌کند بفرستد؛ Admitted load چیزی است که سیستم می‌پذیرد؛ Throughput ممکن است همه responseها را بشمارد؛ Goodput فقط Operationهای درست و در Service-level را می‌شمارد. اگر load shedding زیاد شود، Throughput خام می‌تواند سبز بماند درحالی‌که Outcome مفید سقوط کرده است.

Latency را با میانگین گزارش نکنید

Start/end event، client/server view، Histogram config، p50/p95/p99، timeout bucket و measurement window را Pin کنید. Timeoutها را از Histogram حذف نکنید. Tail latency نزدیک Saturation معمولاً زودتر از میانگین مسئله را نشان می‌دهد.

Coordinated Omission را کنترل کنید

در Generator بسته، وقتی response کند می‌شود، درخواست بعدی دیرتر تولید می‌شود و بدترین دوره کم‌نمونه می‌ماند. Workload model، intended schedule، correction policy و raw histogram را ثبت کنید. ابزار خوب هم با Script یا مدل غلط این خطا را خودکار حل نمی‌کند.

Error، Rejection و Correctness

Transport error، HTTP/Application error، Business failure، overload rejection، timeout، retry، partial result و correctness failure را جدا کنید. پاسخ ۲۰۰ با نتیجه تکراری یا State غلط Goodput نیست. Scalability بدون حفظ correctness یک Claim ناقص است.

Utilization با Saturation فرق دارد

CPU ۶۰٪ لزوماً Headroom ندارد؛ یک Core یا lock ممکن است saturated باشد. CPU throttle، memory/OOM/GC، disk IOPS/latency، network، connection pool، thread pool، queue و downstream limit را ببینید. Saturation یعنی تقاضا پشت Resource محدود صف می‌کشد، نه فقط utilization عدد ۱۰۰.

Knee و Saturation Point

Knee ناحیه‌ای است که marginal load افزایش کوچکی می‌یابد اما latency/queue/error به‌سرعت بدتر می‌شود. یک الگوریتم جهانی برای همه Curveها فرض نکنید؛ Definition، smoothing، confidence و candidate status را ثبت کنید. Saturation candidate پس از تکرار و تشخیص Bottleneck به Claim تبدیل می‌شود.

Capacity را با آخرین Throughput یکی نگیرید

Capacity برای Configuration معین، بیشترین Workload مشاهده‌شده‌ای است که همه Criteria—Latency، Error، Goodput، Correctness، Backlog و saturation—را پاس می‌کند. اگر Step بعدی Fail و فاصله زیاد است، فقط Lower bound داریم. Capacity تاریخ و Build/Config/Data/Dependency دارد.

Capacity Frontier چیست؟

برای هر Resource config، آخرین Cell قابل‌قبول را روی نمودار قرار دهید. اتصال این نقاط Frontier تقریبی Resource→Capacity را می‌سازد. Cell Missing، معیار متفاوت یا Environment drift نباید بی‌خبر در یک خط قرار گیرد. Range و confidence را کنار نقطه نگه دارید.

Scalability Gain و Efficiency

resource_ratio   = resource_candidate / resource_baseline
throughput_ratio = goodput_candidate / goodput_baseline
scalability_gain = goodput_candidate - goodput_baseline
efficiency       = throughput_ratio / resource_ratio
marginal_gain    = delta_goodput / delta_resource

این فرمول‌ها فقط وقتی معنا دارند که Resource unit و Goodput قابل‌مقایسه باشند. CPU×Replica جمع ساده‌ای برای Database tier یا heterogeneous nodes نیست. Efficiency=۱ مرجع خطی است؛ Pass threshold را Architecture/Cost/SLO تعیین می‌کند.

Bottleneck Shift را ثبت کنید

با Scale-out لایه وب، Database، partition، queue، cache، license یا external API ممکن است Bottleneck تازه شود. نتیجه «Web مقیاس‌پذیر است» درباره کل Journey کافی نیست. DependencyID، quota/rate/pool/shard limit و ظرفیت Control plane را به Cell متصل کنید.

Stateful و Stateless را ساده‌سازی نکنید

Stateless frontend معمولاً آسان‌تر Scale-out می‌شود، اما state store، session affinity، cache coherence، locks، transactions، partitions و replicas محدودیت می‌سازند. Stateful به معنای «غیرمقیاس‌پذیر» نیست؛ Strategy و Cost پیچیده‌تر است. Consistency و correctness را قربانی Throughput نکنید.

Data Volume و Data Shape

رکوردهای بیشتر، index age، key distribution/skew، hot partition، object size و cache hit رفتار را عوض می‌کنند. DatasetID/version/digest، cardinality، distribution، state و reset policy لازم‌اند. تست با Database خالی Capacity آینده را نمایندگی نمی‌کند.

Environment و Noisy Neighbor

Provider/region/zone، VM generation، OS/kernel، runtime، orchestrator، database/broker/dependency versions، isolation و noisy-neighbor policy را ثبت کنید. Environment کوچک‌تر از Production می‌تواند Trend مفید بسازد، اما ratio انتقال ظرفیت نیازمند Evidence جداست.

Load Generator هم Capacity دارد

GeneratorID/tool/script، node count، CPU/network، connection pool، clock sync و calibration را Pin کنید. اگر Generator به ۱۰۰٪ CPU یا ephemeral-port limit برسد، Plateau به اشتباه Bottleneck سامانه دیده می‌شود. انتخاب و PoC ابزار در راهنمای ابزار تست عملکرد پوشش داده شده است.

Warm-up، Measurement و Cool-down

JIT، cache، connection pool، autoscaler و data compaction رفتار آغاز Run را تغییر می‌دهند. Windowها را از پیش تعریف و raw time series را حفظ کنید. حذف Warm-up فقط وقتی مجاز است که مبنای سؤال و Policy آن را توجیه کند؛ cold-start خود ممکن است Requirement باشد.

Repeatability و Run order

هر Cell را تکرار کنید و پراکندگی/Confidence را گزارش دهید. اجرای همیشگی R1→R2→R4 می‌تواند cache heat، database growth یا thermal drift را با Resource effect مخلوط کند. Seed، execution order، reset و incident/deviation را Evidence کنید.

Comparability Gate

دو Result فقط وقتی Ratio معنادار می‌سازند که Workload، Dataset، Build (جز تغییر هدف)، Environment policy، Metric semantics و Window قابل‌مقایسه باشند. SPEC برای Benchmark عمومی بر افشای کامل Hardware/Software/Configuration و قابلیت بازتولید تأکید می‌کند؛ Run rules رسمی SPEC CPU را فقط به‌عنوان نمونهٔ انضباط disclosure بخوانید، نه قواعد Benchmark این سامانه.

Performance Regression با Scalability Regression فرق دارد

Build جدید ممکن است در R1 همان p95 را داشته باشد ولی Efficiency R4 افت کند؛ یا R1 کمی کندتر اما frontier بهتر شود. Regression باید Curve/Cell-level و Change claim داشته باشد. تست عملکرد مستمر در CI/CD مالک Baseline و Gate بین Buildهاست.

Elasticity با Scalability یکی نیست

Scalability ایستا می‌پرسد R2 نسبت به R1 چه Curveی دارد. Elasticity پویا می‌پرسد Controller افزایش/کاهش تقاضا را چه زمانی می‌بیند، منابع چه‌قدر دیر Provision/Ready/Warm می‌شوند، overshoot/undershoot چقدر است و scale-in آیا امن است. سامانه می‌تواند دستی مقیاس‌پذیر ولی خودکار کم‌کشش باشد.

داشتن HPA اثبات Elasticity نیست

مستند رسمی Kubernetes HPA آن را Control loop دوره‌ای بر پایه Metric می‌داند و رفتار missing metric، Pod readiness و stabilization را توضیح می‌دهد. پس Test باید Metric source/target/sampling، detection، provisioning، readiness، warm-up، stabilization و چند Metric را مشاهده کند؛ Enabled بودن Resource کافی نیست.

Step-up، Spike و Ramp برای Elasticity

• Step-up برای detection/provisioning delay و transient queue.
• Ramp برای دنبال‌کردن رشد تدریجی و policy threshold.
• Spike برای overshoot/load-shedding و ظرفیت آماده.
• Step-down برای stabilization، scale-in و drain safety.
• Cycle برای oscillation/thrashing و hysteresis.

Scale-in را فراموش نکنید

حذف Instance می‌تواند request در حال اجرا، background job، connection، cache و partition ownership را مختل کند. termination grace، drain، checkpoint، retry/idempotency و residual backlog را تست کنید. هزینه کم‌شده بدون correctness و availability موفق نیست.

Overload یک Failure mode است

Google SRE در راهنمای Launch و Load test توضیح می‌دهد سرویس‌ها نزدیک overload اغلب از رفتار خطی خارج می‌شوند. Overload start/signal، queue growth، retry amplification، admission control، load shedding، degradation، recovery و residual backlog را ثبت کنید؛ این تجربه Google جای معیار سامانه شما نیست.

Load shedding و Goodput

Rejection کنترل‌شده می‌تواند از collapse جلوگیری کند؛ آن را صرفاً Error بد یا Pass خوب ننامید. Policy باید بگوید کدام request، با چه پاسخ و retry hint، در چه سطحی Shed می‌شود. Goodput و User-visible success را همراه offered/admitted/rejected گزارش کنید.

Recovery پس از Overload

وقتی بار کم شد، آیا latency/queue/resource/state برمی‌گردند؟ recovery start/time، backlog drain، circuit state، retry storm، leaked connection و correctness را مشاهده کنید. تست تاب‌آوری و Failure recovery در راهنمای تست تاب‌آوری مالک مستقل دارد.

Cost را به Curve اضافه کنید

Currency، Price snapshot/time/source، provisioned/used resource، test cost، cost/time، cost/request، cost/success، marginal cost، idle، egress و unknown cost را ثبت کنید. Throughput بیشتر با هزینه ده‌برابر ممکن است Strategy خوبی یا بدی باشد؛ Decision به هدف و constraint بستگی دارد.

Cost Efficiency با Performance Efficiency فرق دارد

Goodput/Core و Goodput/ریال دو نسبت متفاوت‌اند. Price tier، commitment، region و زمان قیمت تغییر می‌کنند. نتیجه فنی را از Forecast مالی جدا نگه دارید. ارقام هزینه آزمایشگاه این مقاله واقعی یا توصیه خرید Cloud نیستند.

Capacity Planning یک Forecast است

Test frontier مشاهده گذشته در Environment مشخص است؛ Capacity plan آن را با demand scenario، horizon، growth، peak/seasonality، failure/deployment reserve و uncertainty به آینده می‌برد. Forecast باید Trigger بازبینی داشته باشد. «برای رشد ده‌برابری آماده‌ایم» بدون فرض‌ها ادعای قابل‌ممیزی نیست.

Headroom عدد ثابت جهانی نیست

Reserve به volatility، autoscaling delay، dependency quota، failure domain، deploy capacity، cost و risk بستگی دارد. ۲۰٪ یا ۵۰٪ را بدون سناریو کپی نکنید. Headroom را نسبت به capacity under all criteria بسنجید، نه CPU خام.

Scalability Curve Record

ScalabilityCurveRecord {
  record_id, claim, subject_build_config,
  workload_and_dataset_contracts,
  resource_matrix, environment_and_generator,
  runs_repetitions_deviations,
  offered_admitted_goodput_latency_error_correctness,
  utilization_saturation_bottleneck,
  service_level_and_capacity_frontier,
  gain_efficiency_marginal_gain_cost,
  elasticity_and_overload_if_in_scope,
  evidence_digests, verdicts, findings,
  decision, expiry, correction_history
}

Verdictها را جدا نگه دارید

PERFORMANCE_PASS_AT_R1_W100
SCALABILITY_HOLD_MISSING_CELLS
CAPACITY_LOWER_BOUND_ONLY
ELASTICITY_FAIL_READINESS_DELAY
EFFICIENCY_BELOW_TARGET
COST_INCONCLUSIVE
CORRECTNESS_FAIL_UNDER_OVERLOAD
RUN_INVALID_GENERATOR_SATURATED
EVIDENCE_STALE

Performance Pass یک Cell، Scalability Pass کل Range نیست. Autoscaler behavior نمی‌تواند Curve ایستا را جبران کند. Cost unknown و correctness fail را با Throughput بالا میانگین نگیرید.

Evidence Pack قابل بازتولید

• Claim/System boundary/Service-level/Cost scope
• Build/Config/Topology/Dependency digests
• Workload/Dataset/Generator contracts و calibration
• Matrix، execution order، repetition، window و deviations
• Raw histogram/time series/metrics/traces/logs
• Goodput/error/correctness/saturation computations
• Curve/frontier/efficiency/cost با uncertainty
• Findings، retest، Decision، expiry و Correction

Change و Stale Result

Build، Config، Workload، Dataset، Dependency، price، quota، controller یا incident می‌تواند Result را Stale کند. Impact analysis تعیین کند کدام Cell تکرار شود. Ratio قدیمی را برای معماری تازه یا Region دیگر بی‌خبر reuse نکنید.

آزمایشگاه آفلاین فارسی و کاملاً ساختگی

آزمایشگاه SYN-SCALABILITY-CURVE-01 هیچ شبکه، Cloud، Production، سیستم، شرکت، کاربر، Order، Payment، PSP، بانک، Account، پول، PII، Token یا Credential واقعی ندارد. سرویس، منابع، Workload و Cost همگی Fixture هستند. IRR فقط Label خیالی و تومان presentation-only است.

Service-level (fictional): p95 <= 300ms AND error <= 1%

R1: offered=100, goodput=100, p95=180ms, error=0.1%
    resource_ratio=1, throughput_ratio=1.00, efficiency=1.00, PASS
R2: offered=200, goodput=180, p95=260ms, error=0.8%
    resource_ratio=2, throughput_ratio=1.80, efficiency=0.90, PASS
R4: offered=400, goodput=240, p95=940ms, error=7%
    resource_ratio=4, throughput_ratio=2.40, efficiency=0.60, FAIL

Injected gaps: missing R4@300 cell, fake autoscaler enabled badge,
generator calibration absent, dataset/config unpinned, cost unknown,
timeouts omitted from naive latency, retry duplicates counted as throughput.

False Scalability Claim

Checker سطحی می‌بیند Base سریع است، افزودن منابع Throughput را بالا برده، Autoscaler Enabled و Bug باز صفر است؛ پس می‌گوید FAST_SCALABLE_ELASTIC_AND_COST_EFFICIENT. اما R4 SLO را می‌شکند، Efficiency افت کرده و Capacity/Cost/Elasticity اصلاً اندازه‌گیری نشده‌اند.

Validator قطعی ۳۶۷ کنترل

Validator مستقل و dependency-free کنترل‌ها را در Record/Claim/Subject/Workload/Data/Resource/Environment/Generator/Run/Observation/Latency/Error/Utilization/Service-level/Matrix/Curve/Scalability/Capacity/Elasticity/Dynamic/Dependency/Overload/Cost/Comparison/Evidence/Verdict/Finding/Forecast/Decision/Lifecycle/Boundary یکتا کرد. Assertion اجرای واقعی دقیقاً ۳۶۷ مورد را شمرد.

CONTROL_COUNT=367
SUPERFICIAL=FAST_SCALABLE_ELASTIC_AND_COST_EFFICIENT
CURVE=R1:g100:e1.00:PASS|R2:g180:e0.90:PASS|R4:g240:e0.60:FAIL
AUDIT=HOLD-367
INDEPENDENT_TARGET=real-system-organization-or-traffic:false:PASS
CORRECTED=READY_FOR_SCALABILITY_CURVE_REVIEW-0
BOUNDARY=offline-fictional-fixture-only; no benchmark, capacity,
linear-scaling, cost, production-readiness, reliability, safety,
future-growth, or real-world claim

پس از Pin کردن تمام کنترل‌های ساختگی، خروجی فقط READY_FOR_SCALABILITY_CURVE_REVIEW-0 است. Validator حقیقت Metric، Benchmark validity یا انتقال به Production را اثبات نمی‌کند؛ completeness ساختاری Record را می‌سنجد.

سناریوهای فارسی آزمایشگاه

• شناسه ۷/۷/۷ و ی/ی و ک/ک برای key skew و Label، بدون mutation هویت.
• RTL/LTR و Bidi در Dashboard، بدون تغییر raw metric.
• UTC run/event time، Asia/Tehran display و جلالی presentation-only.
• 7000 IRR canonical و «۷۰۰ تومان» display-only برای cost unit.
• Timeout، retry، duplicate و late completion برای Goodput.
• Hot key، cold/warm cache و dataset growth برای Bottleneck shift.
• Step-up/down و readiness delay برای fake autoscaler.
• Generator saturation و missing histogram bucket برای Invalid run.

دروازه Decision پیشنهادی

اگر Workload/Resource/Service-level Pin نیست، Curve نسازید. اگر Generator saturated یا Metric ناقص است، Run invalid است. اگر Cellهای نزدیک frontier Missing‌اند، Capacity را Lower bound بنامید. اگر correctness Fail است، Throughput را Success ننامید. اگر Cost/Elasticity آزموده نشده‌اند، Claim حذف شود. Decision باید Scope، condition، unknown، evidence، approver و expiry داشته باشد.

۲۰ ضدالگوی رایج

Red flagها: Concurrent users مساوی Workload؛ Performance فقط سرعت؛ Scalability مساوی Load بیشتر؛ Resource بیشتر مساوی Pass؛ رشد باید خطی باشد؛ Autoscaler enabled مساوی Elastic؛ Throughput مساوی Goodput؛ timeout حذف‌شده؛ میانگین به‌جای tail؛ CPU پایین مساوی Headroom؛ utilization مساوی saturation؛ آخرین Throughput مساوی Capacity؛ یک Run بدون تکرار؛ R1/R4 با Dataset متفاوت؛ Generator بدون calibration؛ warm/cold مخلوط؛ Scale-out بدون dependency؛ Cost بدون price snapshot؛ Test frontier مساوی forecast؛ و Capacity گذشته مساوی آمادگی رشد آینده.

چک‌لیست مالک Scalability

• Claim، System boundary، Workload/Resource range و not-claimedها روشن‌اند.
• Build/Config/Topology/Dependencyها digest دارند.
• Open/Closed workload، rate/concurrency/mix/payload/skew نسخه‌دار است.
• Dataset cardinality/distribution/cache/index/reset Pin است.
• Resource configuration و quota/limit دقیق است.
• Environment و Generator کالیبره و قابل بازتولیدند.
• Warm-up/measurement/cool-down/repetition/order ثبت شده‌اند.
• Offered/Admitted/Goodput/Rejected/Timeout تفکیک شده‌اند.
• Latency histogram/tail/timeout/coordinated-omission policy دارد.
• Error/correctness/retry/duplicate/partial result جداست.
• Utilization/queue/backlog/saturation/bottleneck evidence دارد.
• هر Matrix cell Service-level verdict و Missing/Invalid state دارد.
• Gain/Efficiency/frontier با comparability و uncertainty محاسبه شده‌اند.
• Elasticity/Cost/Forecast فقط در صورت Evidence ادعا می‌شوند.
• Decision/expiry/change/retest/correction قابل‌ردیابی است.

پایلوت ۳۰روزه بدون سیستم واقعی

هفته اول Claim/Workload/Data/Resource/Service-level ساختگی؛ هفته دوم Generator calibration و Matrix R1/R2/R4؛ هفته سوم saturation/overload/autoscaler delay/cost fixture؛ هفته چهارم Curve/frontier/comparability/Evidence/Decision/Correction. معیار موفقیت Throughput رکوردی نیست: repeatability، cell completeness، goodput accuracy، bottleneck localization، invalid-run detection و claim scope را بسنجید.

جمع‌بندی

Performance می‌گوید سیستم در یک شرایط تعریف‌شده چگونه رفتار کرد؛ Scalability می‌گوید این رفتار با تغییر Workload و Resource چگونه عوض شد. Capacity مرز Criteria و Elasticity پاسخ زمانی Control loop است. حرفه‌ای‌ترین گزارش، بزرگ‌ترین Throughput را برجسته نمی‌کند؛ Curve، Goodput، tail، correctness، frontier، efficiency، cost، Missing cell و محدودیت تعمیم را کنار هم نگه می‌دارد.

پرسش‌های متداول

تفاوت اصلی تست عملکرد و تست مقیاس‌پذیری چیست؟

Performance رفتار یک Build/Config زیر Workload مشخص را می‌سنجد؛ Scalability چند Resource configuration و Workload step را برای Gain، Efficiency، Saturation و Capacity frontier مقایسه می‌کند.

آیا افزایش Throughput با افزودن سرور یعنی سیستم مقیاس‌پذیر است؟

نه به‌تنهایی. Goodput، latency/error/correctness، resource ratio، efficiency، cost، bottleneck و Range ادعا نیز باید سنجیده شوند.

فرق Scalability و Elasticity چیست؟

Scalability رابطه ظرفیت/عملکرد با منابع است؛ Elasticity کیفیت و سرعت افزودن/کاهش خودکار منابع هنگام تغییر تقاضاست، شامل detection، readiness، stabilization و scale-in.

Capacity را چگونه از تست پیدا کنیم؟

برای هر Configuration، بالاترین Workload مشاهده‌شده‌ای که همه Criteria را پاس می‌کند یک lower-bound معتبر می‌دهد؛ با Stepهای نزدیک‌تر و تکرار، frontier دقیق‌تر می‌شود.

حداقل Scalability Curve Record چه دارد؟

Claim/Subject، Workload/Data/Resource/Environment/Generator، Matrix و Runها، Goodput/latency/error/correctness/resource، SLO/frontier/gain/efficiency، cost/elasticity scope، evidence/verdict/findings، decision/expiry/correction.