JMeter میتواند درخواست تولید کند، زمان نمونهها را ثبت کند و گزارش بسازد؛ اما بهتنهایی نمیداند «کاربر واقعی» چیست، بار مجاز چقدر است، پاسخ درست کدام است یا آیا Generator پیش از سامانهٔ هدف اشباع شده است. صد Thread، صد مشتری نیست؛ RPS بالاتر همیشه بهتر نیست؛ Error نزدیک صفر نیز اگر Assertion ضعیف باشد میتواند سبز کاذب باشد.
این راهنما Apache JMeter را از یک فایل JMX نمایشی به اجرای قابل ممیزی تبدیل میکند: Permission → Performance question → Workload contract → Journey/data/session/oracle → Target fault → Environment/generator manifest → Calibration → CLI run → JTL/telemetry → validity gates → Capacity decision → evidence bundle. تمام مثالها مصنوعیاند و هیچ بار یا ضبطی روی سرویس عمومی، Production یا شخص واقعی اجرا نمیشود.
خلاصهٔ عملی: اجرای معتبر JMeter چه شرطهایی دارد؟
- هدف، دامنه، سقف بار، بازهٔ زمانی، Stop rule و صاحب مجوز مکتوباند.
- Workload از دادهٔ معتبر یا فرضیهٔ صریح میآید، نه عدد گرد ۱۰۰ یا ۱۰۰۰.
- Thread، Connection، Session، Journey، Arrival و Concurrent work جدا تعریف میشوند.
- هر Sampler یک Oracle و Error taxonomy دارد؛ HTTP ۲۰۰ بهتنهایی Pass نیست.
- نسخهٔ JMeter/Java/Plugin/JMX/Properties/Data و Command دقیق Pin شدهاند.
- GUI برای ساخت و Debug محدود است؛ Run اندازهگیریشونده با CLI و Listener سبک انجام میشود.
- Generator headroom، شبکه، Clock و Telemetry همزمان با Target ثبت میشوند.
- Percentile، Throughput و Error فقط در Cohort معتبر و با Missing/Retry/Timeout تفسیر میشوند.
- نتیجه به Build، Environment، Workload و بازهٔ مشاهدهشده محدود و دارای انقضاست.
مرز این راهنما با محتوای Performance سایت
| پرسش | مالک محتوا | خروجی |
|---|---|---|
| اولین درخواست HTTP را در JMeter چگونه بسازم؟ | آموزش JMeter از صفر | شروع ابزار و اولین Test plan |
| Load/Stress/Spike/Soak و Workload model چیست؟ | برنامه تست عملکرد | Performance plan و Acceptance |
| آیا JMeter اصلاً ابزار مناسب است؟ | انتخاب ابزار تست عملکرد | Hard Gate و Tool PoC |
| JMeter، k6 و Gatling چه تفاوتی دارند؟ | مقایسه ابزارهای تست بار | Matched tool comparison |
| منحنی ظرفیت و Scale-out چگونه سنجیده شود؟ | تست مقیاسپذیری | Capacity curve و bottleneck transition |
| رگرسیون Performance در Pipeline چگونه باشد؟ | تست عملکرد در CI/CD | Comparable baseline automation |
| اجرای JMeter چگونه معتبر و قابل تحویل شود؟ | همین مقاله | Execution validity و Evidence bundle |
پس این صفحه دوباره آموزش کلی Performance یا مسابقهٔ ابزارها نیست. تمرکز آن روی شکاف میان «JMX اجرا شد» و «داده برای تصمیم ظرفیت معتبر است» قرار دارد.
منابع رسمی چه چیزی را میگویند و چه چیزی را نه؟
صفحهٔ رسمی تغییرات Apache JMeter در وضعیت فعلی میگوید شاخهٔ ۵.۶.x برای اجرا Java ۸ یا جدیدتر میخواهد و Java ۱۷ یا جدیدتر توصیه شده است. این جمله مجوز استفاده از هر Java build یا تضمین سازگاری Pluginهای شما نیست؛ Distribution، معماری و Hash باید در Manifest همان Run ثبت شوند.
راهنمای رسمی ساخت Test plan عناصر Thread group، Controller، Sampler، Listener، Timer، Assertion و Configuration را معرفی میکند. صفحهٔ عناصر Test plan توضیح میدهد هر Thread مسیر Plan را مستقل اجرا میکند و Threadها برای شبیهسازی اتصالهای همزمان بهکار میروند. این قابلیت ثابت نمیکند هر Thread معادل یک انسان، Device یا Session تولیدی است.
Best Practices رسمی JMeter اجرای CLI و حذف/غیرفعالکردن Listenerهای سنگین مانند View Results Tree هنگام Load run را توصیه میکند. این Practice اثر Observer را کاهش میدهد، اما Generator capacity را اثبات نمیکند. Dashboard generator نیز از Result log گزارش HTML میسازد؛ نمودار تولیدشده صحت Workload، Oracle یا Target telemetry را تضمین نمیکند.
Permission Gate پیش از اولین Request
Performance Test Permission permission-id / issuer / authority source target hosts, IPs, APIs and excluded dependencies environment / tenant / data classification allowed methods, rate, concurrency and total volume window / timezone / duration source generator IPs and identities monitoring and incident contacts stop conditions / emergency kill owner third-party/CDN/payment exclusions evidence retention / review-at / expiry
تست بار بدون مجوز میتواند اختلال، هزینه، Rate-limit، Alert یا نقض قرارداد ایجاد کند. مالک Product همیشه اختیار بارزدن به CDN، درگاه پرداخت، سرویس پیامک یا API شخص ثالث را ندارد. برای ساخت Permission stack به راهنمای مجوز فعالیت تست رجوع کنید.
سؤال Performance را به تصمیم وصل کنید
«آیا سایت سریع است؟» قابل اجرا نیست. سؤال نمونه: «آیا Build B17 در Environment E3، Mix ثبتشدهٔ خرید را برای Arrival profile P تا بازهٔ ۲۰ دقیقه، با p95 زیر Threshold قراردادی، Errorهای مجاز طبقهبندیشده و Saturation headroom تعیینشده نگه میدارد؟». Threshold باید از SLO، Product need یا Risk decision بیاید؛ عدد اینترنتی جای Source را نمیگیرد.
Performance Decision Contract decision-id / question / stakeholder product build / environment / topology journeys and population load model / profile / duration response and throughput definitions error budget and excluded errors resource/headroom constraints accept / hold / stop / investigate outcomes evidence owner / review / expiry
Workload Source را قابل ردگیری کنید
Workload میتواند از Telemetry تولید، Forecast کمپین، Contract، Capacity target یا Hypothesis آزمایشگاهی بیاید. Source، بازه، timezone، Sample، bot filtering، retry، cache، missing data و seasonality را ثبت کنید. اگر داده ندارید، «فرضیه» بنویسید؛ عدد فرضی را «ترافیک واقعی» ننامید.
Workload Evidence Record source-id / owner / captured-at population and observation window request, session and journey definitions arrival distribution / concurrency observation journey mix and abandonment think-time/pacing distribution payload/data cardinality retry/bot/cache/internal traffic policy missingness / bias / forecast transform expiry and correction
Thread با User، Session و Arrival یکی نیست
| واحد | معنا | خطای رایج |
|---|---|---|
| Thread | مسیر اجرایی JMeter با state خودش | نامیدن آن بهعنوان انسان واقعی |
| Connection | رابط شبکهای که ممکن است reuse شود | یکیگرفتن با Thread |
| Session | دنبالهٔ تعامل با هویت/state | نادیدهگرفتن cookie/token expiry |
| Journey | دنبالهٔ Business action و Oracle | شمارش هر Request بهعنوان Journey |
| Arrival | ورود کار تازه در زمان | استنباط مستقیم از Thread count |
| Concurrency | کار همزمان در یک Boundary تعریفشده | یک عدد بدون محل اندازهگیری |
یک Thread ممکن است چند Journey اجرا کند یا هنگام Think time هیچ Request فعالی نداشته باشد. یک انسان ممکن است چند Tab/Device/Session داشته باشد. در Report همواره بنویسید «JMeter threads» مگر Mapping و محدودیت آن را اثبات کرده باشید.
Closed و Open workload را آگاهانه انتخاب کنید
Thread Group کلاسیک معمولاً یک مدل بسته میسازد: کار بعدی هر Thread پس از پیشرفت همان Thread رخ میدهد و کندشدن Target میتواند نرخ تولید را نیز پایین بیاورد. در مدل Arrival محور، ورود کار مستقلتر از پاسخ هدف تعریف میشود. هیچکدام همیشه واقعیتر نیست؛ Population و سؤال تصمیم تعیین میکند. Plugin یا Controller مربوط به Arrival باید نسخهدار و جدا اعتبارسنجی شود.
Journey mix را در سطح Business نگه دارید
Mix نمونه میتواند Browse ۵۰%، Search ۲۵%، Checkout ۱۵% و Reconciliation ۱۰% باشد، اما درصد بدون Source صرفاً Fixture است. هر Journey Count، Success semantics، data need، session boundary و downstream fan-out دارد. Mix اجراشده را از Mix برنامهریزیشده مقایسه کنید؛ Failure زودهنگام ممکن است بخشهای بعدی را کمنمونه کند.
Arrival profile فقط Ramp-up خطی نیست
Start، ramp، plateau، step، burst، recovery و cool-down را بر اساس سؤال تعریف کنید. توصیهٔ «Ramp-up برابر تعداد Thread یا نصف آن» نقطهٔ شروع آموزشی است، نه قانون ظرفیت. Profile باید Time bucket، target rate/concurrency، tolerance و actual achieved load داشته باشد.
Load Profile phase-id / start-offset / duration model: closed / arrival-oriented target threads / arrivals / iterations ramp or step shape / tolerance journey mix / pacing / data pool expected achieved-load band stop and recovery criteria actual achieved load / deviation reason
Think time و Pacing دو مفهوم متفاوتاند
Think time فاصلهٔ رفتار میان Actionهای Journey است؛ Pacing فاصله یا نرخ تکرار Journey را کنترل میکند. Constant timer سهثانیهای رفتار واقعی را اثبات نمیکند و میتواند Burst مصنوعی بسازد. Distribution، حداقل/حداکثر، همبستگی با Journey و Seed تصادفی را ثبت کنید.
رابطهٔ Concurrency، Throughput و زمان را اندازه بگیرید
در شرایط پایدار و با تعریفهای سازگار، Concurrency مشاهدهشده با نرخ و زمان در سیستم ارتباط دارد؛ اما Ramp، Queue، Retry، timeout، abandonment و Sample boundary این رابطه را میشکنند. از یک فرمول برای تبدیل کور Thread به RPS استفاده نکنید. هر سه را در Generator و Target اندازه بگیرید و اختلاف را توضیح دهید.
Test data بخشی از Workload است
یک محصول ثابت برای هزار Thread، Cache hit و Lock contention متفاوتی از هزار محصول یکتا میسازد. Cardinality، skew، hot keys، account reuse، tenant distribution، inventory state و cleanup را قرارداد کنید. برای چرخهٔ داده از مدیریت داده تست استفاده کنید.
Data Manifest dataset-id / generator / seed / version schema / encoding / delimiter / timezone identity and tenant pools unique/reusable/exhaustion policy hot-key and distribution profile secret/PII status and redaction setup / namespace / cleanup / verification CSV sharing mode / EOF / recycle policy owner / expiry
CSV را بدون Exhaustion policy اجرا نکنید
CSV Data Set Config میتواند داده را میان Threadها به شیوههای مختلف مصرف کند. Encoding، delimiter، header، sharing mode، recycle، stop-thread-on-EOF و تعداد ردیف باید Pin شوند. مقدار تکراری یا EOF خاموش میتواند Login failure یا contention مصنوعی بسازد.
Session و Cookie را با Boundary واقعی مدل کنید
Cookie Manager تنها آغاز کار است. Login frequency، token TTL/refresh، logout، connection reuse، CSRF، tenant switch و session invalidation را ثبت کنید. Reusing یک Token ثابت برای همهٔ Threadها ممکن است مسیر Authorization و Cache را تحریف کند یا Credential را در JMX/JTL نشت دهد.
Correlation را بهعنوان Dataflow مستند کنید
Correlation Record variable-id / producer sampler source field / extractor / cardinality required/optional / null behavior transform / encoding / validation consumer samplers scope and thread/session boundary redaction and logging policy positive/negative fixture / owner
Extractor سبز بدون Assertion ممکن است مقدار خالی را به Request بعدی ببرد و آن Request با صفحهٔ خطای HTTP ۲۰۰ «موفق» شود. هر Correlation critical یک existence/shape assertion و failure route میخواهد.
Recorder خروجی نهایی تولید نمیکند
HTTP(S) recorder میتواند ترافیک مجاز را Capture کند، اما فایل خام شامل asset، analytics، token، cookie، PII و درخواستهای خارج از Scope است. Certificate/proxy فقط در محیط تحت کنترل و با رضایت استفاده شود. Record را پاکسازی، parameterize، correlate، assert و Review کنید؛ ضبط App عمومی بدون مجوز پذیرفته نیست.
Assertion باید Business failure را ببیند
Status code، schema، required fields، state، amount، currency، idempotency، tenant و side effect میتوانند Oracle باشند. «Response contains Success» ممکن است Error page یا متن stale را بپذیرد. Assertion cost نیز روی Generator اثر دارد؛ correctness را حذف نکنید، بلکه هزینه را کالیبره و مکان مناسب را انتخاب کنید.
Sampler Oracle sampler-id / journey step transport expectation schema and required fields business state and side-effect oracle timeout semantics allowed/rejected response classes correlation assertions evidence saved on failure redaction / owner / limits
Target Fault قبل از Load بزرگ اجرا شود
- HTTP ۲۰۰ با State اشتباه.
- تبدیل نادرست IRR/تومان در Boundary نمایشی.
- Callback تکراری با دو اثر Ledger.
- Response متعلق به Tenant دیگر.
- Token منقضی و refresh loop.
- Timeout با Side effect انجامشده.
- Error payload شامل Secret/PII.
- CSV exhaustion و reuse هویت.
- Cleanup ناقص و آلودگی Run بعدی.
- Generator drop که به Target success نسبت داده میشود.
Faultها فقط در Stub یا Environment مجاز تزریق شوند. اگر Plan این Faultهای حیاتی را تشخیص نمیدهد، افزایش Thread صرفاً خطای معتبرسازی را بزرگتر میکند.
Error taxonomy را پیش از Run تعریف کنید
| کلاس | مثال | مالک بررسی | آیا در Error budget؟ |
|---|---|---|---|
| Business reject | موجودی ناکافی مورد انتظار | Product/QA | طبق Contract |
| Application | State/5xx نامعتبر | Service team | معمولاً بله |
| Dependency | PSP stub timeout | Dependency owner | بر اساس Scope |
| Generator | Socket/CPU exhaustion محلی | Performance owner | Run invalid/جدا |
| Script | Extractor/CSV/assertion خطا | Test owner | Run invalid/جدا |
| Safety stop | Threshold حفاظتی | Test commander | Evidence توقف |
Error rate نباید همیشه صفر فرض شود؛ بعضی Rejectهای Business بخشی از Mix هستند، اما باید Expected و جدا باشند. برعکس HTTP ۲۰۰ با Oracle fail Error واقعی است. Denominator و Missing sample را روشن کنید.
Retry میتواند Load و معنا را تغییر دهد
Transport یا client ممکن است Retry کند؛ Plan نیز ممکن است Logic retry داشته باشد. Attempt، backoff، idempotency و final outcome را ثبت کنید. Retry پنهان RPS و latency کاربر را تغییر میدهد و Side effect تکراری میسازد. Properties مربوط به HTTP implementation بخشی از Manifest هستند.
Timeout یک Observation window است، نه علت
Connect/read/overall timeoutها باید از Decision contract بیایند. Timeout کوتاه میتواند Queue را قطع و Retry storm بسازد؛ طولانی میتواند Thread را حبس کند. Server ممکن است پس از timeout اثر را کامل کرده باشد؛ Reconciliation لازم است. Timeout را علت Bottleneck ننامید.
Environment Manifest برای مقایسه ضروری است
Target Environment Manifest environment-id / product build / commit service topology / replicas / instance types database/cache/queue versions and sizing feature flags / config / limits dataset snapshot and tenant namespace autoscaling / warm state / scheduled jobs network/CDN/proxy/TLS path observability versions and sampling background traffic / change freeze owner / captured-at / drift check
Run امروز با Replica بیشتر، cache گرم یا background job خاموش با Baseline قبلی Comparable نیست. Difference را پنهان نکنید؛ Cohort جدید بسازید یا INCONCLUSIVE گزارش کنید.
JMeter Manifest را کنار JMX نگه دارید
JMeter Run Manifest run-id / JMeter version + archive hash Java distribution/version/architecture OS/kernel/container/image digest JMX commit/hash plugins + versions + source jmeter.properties/user.properties hashes CLI command and environment variables CSV/data hashes / secrets injection path result-save properties / report config generator nodes/resources/network/clock owner / start/end / exit code
JMX بهتنهایی کافی نیست؛ Propertyها رفتار HTTP، Result، retry، timestamp و distributed mode را تغییر میدهند. Plugin Manager یا دانلود لحظهٔ Run میتواند Supply-chain و Drift بسازد. Artifactهای مورد اعتماد را Pin و تهیهٔ آنها را در شرایط ایران بهصورت تاریخدار آزمون کنید.
GUI برای Design/Debug، CLI برای Measurement
GUI برای مشاهدهٔ یک یا چند Sample، ساخت Plan و پیدا کردن Correlation مفید است. Load run را با CLI و Listenerهای سنگین غیرفعال اجرا کنید. Command رسمی نمونه:
jmeter -n -t plan.jmx -l result.jtl -e -o report-dir # مسیر report-dir باید طبق راهنمای رسمی برای خروجی آماده باشد. # Secret را در command history یا JMX hard-code نکنید. # exit code، stdout/stderr و manifest را کنار result نگه دارید.
این Command صرفاً اجرای فنی است. قبل از آن Smoke/Calibration و پس از آن Integrity check لازم است. نام فایل، overwrite/append policy و فضای دیسک را کنترل کنید تا JTL Runهای مختلف قاطی نشود.
Result-save policy هم دقت میسازد هم هزینه
Properties Reference رسمی Fieldهای ذخیرهٔ CSV/JTL، timestamp، assertion message، response data و batching را مستند میکند. ذخیرهٔ Body همهٔ پاسخها میتواند دیسک/حافظه و محرمانگی را خراب کند؛ ذخیرهٔ بیشازحد کم نیز Diagnosis را دشوار میکند. Minimal-on-success و bounded-redacted-on-error را طراحی و کالیبره کنید.
Smoke، Validation و Calibration سه Gate جدا هستند
| Gate | پرسش | بار | خروجی |
|---|---|---|---|
| Functional smoke | Journey/Correlation/Oracle درست است؟ | حداقل | Pass/Fault detection |
| Plan validation | ساختار و مسیر اجرا میشود؟ | Validation policy | Config findings |
| Generator calibration | Generator بار خواسته را بدون اشباع تولید میکند؟ | Stub/controlled target | Headroom curve |
| Target rehearsal | Safety/telemetry/runbook کار میکند؟ | پایین و محدود | Go/Hold |
Validation feature ممکن است Timer یا Backend listener را طبق Property نادیده بگیرد؛ نتیجهٔ آن Load rehearsal نیست. Generator calibration نیز با Target واقعی قاطی نشود؛ هدفش تعیین ceiling و overhead ابزار است.
Generator saturation را با Headroom Gate تشخیص دهید
Generator Health Record node-id / CPU / load / memory / GC network send/receive / socket errors disk write / JTL queue / file growth active threads / achieved arrivals/RPS client connection pool / DNS/TLS errors clock offset / pause events target stub response baseline headroom threshold / breach interval decision: VALID / SUSPECT / INVALID
اگر achieved load از target عقب میماند همزمان با CPU/GC/network pressure Generator، کندی را به Target نسبت ندهید. Headroom را در تمام Phaseها ببینید، نه فقط Average کل Run. عدد «یک لپتاپ هزار Thread» یا «یک Node دو هزار User» قابل تعمیم نیست.
Distributed testing فقط افزودن Worker نیست
راهنمای رسمی Distributed testing Controller و Workerها را توضیح میدهد و بر CLI در اجرای واقعی تأکید دارد. JMeter/Java/Plugin/JMX/Data/Properties/Clock باید میان Nodeها سازگار باشند. شبکهٔ کنترل، batching، Result transport و failure یک Worker میتواند Sample را تغییر دهد.
Distributed Node Receipt node-id / image/hash / JMeter/Java/plugins JMX/data/properties hashes CPU/RAM/network/clock offset assigned threads or arrivals start/stop/heartbeat samples produced/sent/dropped error and retry summary controller receipt / reconciliation cleanup / owner
Clock alignment برای Timeline ضروری است
Generator، service، database، queue و telemetry باید offset قابل مشاهده داشته باشند. Timestamp start/end semantics و timezone را Pin کنید. Clock drift میتواند Cause را جابهجا و percentile bucket یا trace correlation را خراب کند. Jalali فقط نمایش باشد؛ Canonical timestamp را UTC با timezone ثبت کنید.
Target telemetry را همزمان و کماثر بگیرید
- Service: request rate، latency distribution، error class، concurrency/queue.
- Runtime: CPU، memory، GC، threads/event loop، pauses.
- Database: connection pool، query latency، locks، cache hit، replication.
- Queue: ingress/egress، depth، age، retry/dead-letter.
- Infrastructure: CPU steal، disk/network، autoscaling، throttling.
- Dependency: latency/error/rate-limit با Scope و stub/real label.
Telemetry sampling، aggregation و retention بر نتیجه اثر دارد. Dashboard monitoring «علت» را خودکار نشان نمیدهد؛ Timeline، trace و experiment لازم است. Observability overhead را در Calibration بسنجید.
Stop rule از Fail threshold مهمتر است
Safety Stop Matrix signal / source / window warn threshold / stop threshold who observes / who commands stop automated or manual action cool-down and containment target and generator verification incident route / evidence preserved resume authorization / next attempt
Data corruption، cost spike، queue age، replica instability، error burst، dependency harm یا generator failure میتواند Stop بسازد. Stop موفق شکست پروژه نیست؛ اجرای کنترل ایمنی است. Abort method و cleanup را پیش از Run تمرین کنید.
Warm-up را از Measurement window جدا کنید
JIT، connection pool، cache، autoscaling و lazy initialization میتوانند شروع Run را متفاوت کنند. Warm-up را حذف یا پنهان نکنید؛ Phase جدا با دلیل و داده گزارش کنید. اگر هدف cold-start است، Warm-up نباید آن را پاک کند. Steady-state باید با معیار، نه با چشم، تشخیص داده شود.
Sample را با Transaction اشتباه نگیرید
Sampler یک Request/result تولید میکند؛ Business transaction ممکن است چند Sampler، queue و side effect داشته باشد. Transaction Controller و naming policy را مشخص کنید. Throughput Request با Throughput Order یکی نیست. Parent/subresult و success aggregation باید در JTL/report contract ثبت شود.
Throughput بالاتر همیشه Outcome بهتر نیست
Glossary رسمی JMeter Throughput را تعداد Request در واحد زمان از آغاز اولین تا پایان آخرین Sample تعریف میکند. افزایش آن میتواند ناشی از حذف Think time، Failure سریع، Cache متفاوت یا Mix سادهتر باشد. آن را با Valid business completions، latency، errors، resource و achieved workload بخوانید.
Average را کنار Distribution و Count بگذارید
p50، p90، p95، p99، max و histogram فقط با N کافی و Sample definition ثابت معنا دارند. Tail کمنمونه ناپایدار است؛ percentile aggregation از percentileهای Nodeها معتبر نیست مگر Raw/merge method درست باشد. Missing/aborted/timeout sample را حذف خاموش نکنید.
Metric Record metric-id / definition / unit population / sampler-or-transaction window / phase / timezone N / missing / excluded / retry handling aggregation and percentile method generator vs target source threshold source / uncertainty comparison cohort / owner / expiry
Dashboard را با JTL Integrity شروع کنید
پیش از دیدن HTML، Header/schema، row count، timestamp range، label cardinality، malformed rows، duplicate merge، file truncation و run-id را بررسی کنید. Report directory و input JTL نباید از Run قبلی باقی مانده باشند. APDEX threshold و percentile properties باید در Report manifest باشند.
JTL Integrity Receipt run-id / file hash / size schema and save-service properties hash first/last timestamp / expected window rows / labels / success-fail counts malformed / duplicate / missing node receipts timezone / clock correction report command/config/hash integrity result / reviewer
Capacity point را یک عدد جادویی ندانید
Capacity به Workload، build، topology، SLO، error budget، cost و headroom وابسته است. یک Step series با Recovery و تکرار بسازید و تغییر شیب latency، queue، errors و resource را ثبت کنید. «حداکثر User» بدون Journey/pacing/duration/environment معنای انتقالپذیر ندارد.
Bottleneck یک Hypothesis است تا وقتی آزمایش شود
CPU بالا علت قطعی نیست؛ میتواند اثر باشد. Timeline و dependency را بررسی، یک Intervention محدود و قابل rollback انجام، سپس Profile همسان را تکرار کنید. Config تغییرکرده، Warm state و background traffic را ثبت کنید. «JMeter نشان داد DB کند است» بدون Target evidence ادعای بیشازحد است.
Comparison Gate برای Baseline و Candidate
- Performance question و threshold یکسان.
- Product config و topology یا Difference ثبتشده.
- JMeter/Java/Plugin/JMX/Property/Data یکسان.
- Load profile و achieved load در tolerance.
- Generator/network/clock health معتبر.
- Warm/cold state و background traffic همسان.
- Error/Retry/Timeout/Missing semantics ثابت.
- Telemetry/aggregation/report config یکسان.
- چند Run مستقل با ترتیب یا زمان کنترلشده.
- Effect، uncertainty و practical significance گزارششده.
اگر Gate رد شد، Difference توصیفی است نه رگرسیون علّی. Baseline قدیمی که Package، Browser، Dataset یا autoscaling آن نامعلوم است مرجع تصمیم نیست.
Evidence Bundle باید Run را بازسازی کند
Performance Evidence Bundle permission and decision contracts workload source/model/profile environment and generator manifests JMX/properties/plugins/data hashes CLI command/logs/exit/node receipts JTL integrity and dashboard config target/generator telemetry snapshots fault/calibration/safety-stop evidence analysis notebook or query version findings/limits/decision/review/expiry
Secret، Token، Account، Payload حساس و IP غیرضروری را حذف کنید. Hash اثبات محتوای شناختهشده است، نه صحت آن. Bundle باید Receiver بتواند بدون توضیح شفاهی، Scope و محدودیت را بفهمد.
گزارش Performance باید Claim محدود بسازد
Finding Record finding-id / decision question claim bounded to build/environment/profile/window evidence anchors observed effect and uncertainty generator/target validity gates alternative explanations user/business interpretation limits recommended action / owner retest condition / expiry
بهجای «سیستم ۱۰هزار کاربر را تحمل میکند» بنویسید: «در Profile P، Build B، Environment E و Runهای معتبر R1–R3، achieved arrival و outcomeهای ثبتشده تا Step S در Threshold بودند؛ خارج از این Mix/مدت/Topology آزموده نشده است.»
شرایط ایران و Supply chain را تاریخدار کنید
دسترسی Apache archive، Maven/plugin source، Container registry، Cloud generator، monitoring و DNS ممکن است در زمان/شبکه متفاوت باشد. Download از Mirror ناشناس یا خاموشکردن TLS validation نسخهٔ امن نیست. Source، Hash، License، Proxy/mirror، cache و fallback مجاز را با observed-at ثبت کنید.
هزینه و Cleanup پس از Run را فراموش نکنید
Cloud egress، autoscaling، queue backlog، log volume، پیامک/ایمیل، data growth و حسابهای ساختگی هزینه و Residual میسازند. Budget alert، dry-run، stub، namespace و cleanup verification لازم است. خاموشکردن Generator پایان Run نیست؛ Target باید به baseline recovery برسد.
Cleanup and Recovery Receipt run-id / stop time generated entities by type/count cleanup command / result / residuals queue/backlog drain and age autoscaling return / cache policy test accounts/tokens revoke artifact retention/deletion target recovery metrics owner / verified-at / exception
هوش مصنوعی در ساخت JMX باید محدود باشد
AI میتواند Skeleton، JQL-like analysis یا توضیح Log پیشنهاد دهد، اما Workload source، Permission یا Oracle نیست. Prompt/context، model/version، generated diff، reviewer، accepted/rejected تغییر و secret boundary را ثبت کنید. Plugin/API ناموجود، Property قدیمی و Assertion ضعیف را با مستند رسمی و Fixture تأیید کنید.
آزمایشگاه آفلاین ایرانی SYN-JMETER-PERF-IR-۰۱
برای آزمودن روش، یک Target و Generator کاملاً درونحافظهای ساختیم: Checkout/Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation با IRR canonical و تومان صرفاً نمایشی. هیچ System، User، Account، Credential، Payment، Generator، Network یا Capacity decision واقعی هدف نبود و هیچ Request از Lab خارج نشد.
Fixture شامل ارقام فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی صرفاً presentation بود. Identity، Token، Domain، IP و Telemetry همگی Dummy بودند. Clock offset، CSV exhaustion، duplicate callback و generator pressure عمداً قابل تزریق شدند.
اجرای بد آزمایشگاه چگونه Capacity جعلی ساخت؟
نسخهٔ بد JMeter را استاندارد طلایی و تضمین پایداری نامید؛ ۱۰۰ Thread را ۱۰۰ کاربر واقعی دانست؛ Constant timer سهثانیه گذاشت؛ یک Account و محصول را میان همه share کرد؛ فقط HTTP ۲۰۰ را Pass شمرد؛ Retry را پنهان کرد؛ View Results Tree را روشن گذاشت؛ روی لپتاپ GUI اجرا کرد و از یک Run نتیجه گرفت RPS بالاتر همیشه بهتر، Error باید صفر و لپتاپ همیشه هزار User میسازد.
Checker سطحی همین شعارها را موفقیت دانست و بهاشتباه نوشت:
JMETER_GOLD_STANDARD_THREAD_EQUALS_USER_HIGHER_RPS_ZERO_ERROR_LAPTOP_1000_READY
Validator چرا HOLD-۹۸۰ داد؟
Validator مستقل، قطعی و بدون وابستگی خارجی دقیقاً ۹۸۰ کنترل یکتا را در ۷۰ گروه Identity، As-of، Decision، Permission، Authority، Target، Scope، Risk، Question، Requirement، Workload، Population، Journey، Mix، Arrival، Concurrency، Throughput، Think time، Pacing، Duration، Ramp، Step، Steady، Spike، Stress، Soak، Data، Identity pool، Session، Correlation، Authentication، Oracle، Assertion، Fault، Error، Retry، Timeout، Environment، Build، Dependency، JMeter، Java، Plugin، JMX، Property، CLI، Listener، JTL، Dashboard، Generator، Resource، Distributed، Network، Clock، Telemetry، Target metric، Percentile، Sample، Warm-up، Comparison، Capacity، Bottleneck، Safety، Stop، Cleanup، Evidence، Report، Review، Expiry و Correction شمرد. ID فاقد Group یا تکراری رد شد.
HOLD-980 NO_REAL_SYSTEM_USER_ACCOUNT_CREDENTIAL_PAYMENT_GENERATOR_NETWORK_CAPACITY_PASS
Hold دربارهٔ کیفیت JMeter یا Target نبود؛ Run برای استنتاج معتبر نبود. قاعدهٔ مستقل نبود Target واقعی را تأیید کرد. Validator ظرفیت، Performance تولید، امنیت، رفتار کاربر یا سلامت زیرساخت را اثبات نمیکند.
تعمیر Fixture و نتیجهٔ محدود
Permission و سؤال تصمیم Pin شدند؛ مدل Arrival/Journey/Mix/Data/Session جدا شد؛ Account pool و CSV exhaustion policy ساخته شد؛ State/Amount/Idempotency/Tenant Oracle و ده Fault فعال شدند؛ JMeter/Java/JMX/Property/CLI Pin شد؛ GUI و Listener سنگین کنار رفت؛ Generator روی Stub کالیبره و Headroom ثبت شد؛ Clock/telemetry همتراز، JTL integrity و Cleanup بررسی و سه Run مستقل اجرا شدند.
READY_FOR_JMETER_EXECUTION_VALIDITY_REVIEW-0
صفر فقط یعنی در Fixture مصنوعی همهٔ فیلدهای تعریفشده مقدار و صاحب داشتند. تصمیم مجاز «آماده برای بازبینی اعتبار اجرا» بود؛ نه پذیرش ظرفیت، تضمین پایداری، برتری ابزار یا توصیهٔ بار واقعی.
۲۸ ضدالگوی اجرای JMeter
- JMeter استاندارد طلایی و تضمین پایداری است.
- Thread همان کاربر واقعی است.
- عدد گرد ۱۰۰/۱۰۰۰ Workload است.
- Ramp برابر Thread قانون عمومی است.
- Constant timer رفتار واقعی میسازد.
- RPS بالاتر همیشه بهتر است.
- Error همیشه باید صفر باشد.
- HTTP ۲۰۰ همیشه Pass است.
- Average تنها معیار است.
- یک Run ظرفیت را ثابت میکند.
- یک Account برای همه Threadهاست.
- CSV exhaustion کنترل نمیشود.
- Token در JMX/CSV است.
- Recorder مستقیم به Load test میرود.
- Retry و Timeout پنهاناند.
- GUI برای Measurement استفاده میشود.
- View Results Tree زیر بار روشن است.
- JMX بدون Property/Plugin manifest است.
- JTLهای چند Run Append میشوند.
- Generator health دیده نمیشود.
- لپتاپ ceiling عمومی دارد.
- Distributed workerها Drift دارند.
- Clockها همتراز نیستند.
- Target telemetry وجود ندارد.
- Stop rule و Emergency owner نیست.
- Bottleneck از یک نمودار علتسازی میشود.
- Production/third party بدون مجوز بار میگیرد.
- Cleanup و expiry ثبت نمیشود.
چکلیست ۵۰ نقطهای پیش از Run
- Permission و Authority معتبر است.
- Target و third-party exclusion روشن است.
- Window/Timezone/Generator IP ثبت است.
- Safety stop و kill owner تمرین شده است.
- Performance question به Decision وصل است.
- Threshold Source دارد.
- Build/Environment Manifest کامل است.
- Workload Source و bias ثبت است.
- Thread/User/Session/Arrival جدا هستند.
- Closed/Open model صریح است.
- Journey mix Source دارد.
- Arrival profile phase/tolerance دارد.
- Think time و Pacing جدا هستند.
- Data cardinality/skew ثبت است.
- CSV encoding/sharing/EOF مشخص است.
- Identity pool و cleanup کافی است.
- Session/token TTL/refresh مشخص است.
- Correlation existence/shape assertion دارد.
- Recorder data پاکسازی شده است.
- هر Sampler Oracle دارد.
- Faultهای حیاتی آشکار میشوند.
- Error taxonomy و denominator روشن است.
- Retry attempt جدا ثبت است.
- Timeout و side-effect reconciliation روشن است.
- JMeter/Java archive/hash Pin است.
- Plugin/JMX/Property/Data hash ثبت است.
- Secret injection خارج از JMX است.
- CLI command و exit code ثبت است.
- Listenerهای سنگین خاموشاند.
- Result-save policy کمینه و کافی است.
- Functional smoke گذشت.
- Plan validation محدودیتش ثبت است.
- Generator calibration روی Stub گذشت.
- Generator headroom در کل Run معتبر است.
- Distributed nodeها hash/clock یکسان دارند.
- Network path و DNS/TLS ثبت است.
- Target telemetry همزمان است.
- Clock offset اندازهگیری شده است.
- Warm-up/Measurement window جداست.
- Achieved load در tolerance است.
- Sample/Transaction semantics ثابت است.
- N/Missing/Excluded/Retry گزارش میشود.
- Percentile method ثابت است.
- JTL integrity گذشت.
- Dashboard config/threshold hash ثبت است.
- Comparison gate برای Baseline گذشت.
- Claim به Scope محدود است.
- Cleanup/Recovery تأیید شده است.
- Evidence bundle redacted است.
- Owner/Review/Expiry/Correction ثبت است.
برنامهٔ ۳۰روزهٔ Lab بدون هدف واقعی
روزهای ۱ تا ۳ Permission/Decision؛ ۴ تا ۷ Workload/Journey/Mix؛ ۸ تا ۱۰ Data/Session/Correlation؛ ۱۱ تا ۱۳ Oracle/Fault/Error؛ ۱۴ تا ۱۶ JMeter/Java/JMX/Properties/CLI؛ ۱۷ تا ۱۹ Generator calibration/distributed/clock؛ ۲۰ تا ۲۲ Target telemetry/safety/recovery؛ ۲۳ تا ۲۵ سه Run همسان/JTL integrity؛ ۲۶ تا ۲۷ comparison/capacity hypothesis؛ ۲۸ Evidence bundle؛ ۲۹ blind review؛ ۳۰ Decision/expiry. همهچیز محلی و مصنوعی است.
سوالات متداول JMeter و تست بار
آیا ۱۰۰ Thread در JMeter یعنی ۱۰۰ کاربر همزمان؟
نه لزوماً. Thread مسیر اجرایی JMeter است. Mapping به User/Session/Connection به Journey، Think time، Loop، token، connection reuse و مدل بار بستگی دارد. در گزارش از عبارت دقیق JMeter threads استفاده کنید.
برای تست سنگین از GUI یا CLI استفاده کنیم؟
GUI برای Design و Debug کوچک مناسب است؛ راهنمای رسمی برای Load run حالت CLI و Listenerهای سبک را توصیه میکند. بااینحال CLI بهتنهایی Generator headroom یا اعتبار Workload را تضمین نمیکند.
حداکثر چند کاربر را یک لپتاپ با JMeter میسازد؟
عدد عمومی وجود ندارد. Protocol، TLS، payload، assertion، listener، pacing، Java/GC، CPU/RAM/network و Target latency تعیینکنندهاند. روی Stub کنترلشده Calibration curve و Headroom gate بسازید.
آیا p90 زیر دو ثانیه یعنی تست موفق است؟
فقط اگر Threshold منبع معتبر داشته باشد، Population/Sample/Window درست باشد، achieved load مطابق Contract باشد، Error/Fault/Generator gates بگذرند و دیگر Guardrailها نقض نشوند. یک Percentile بهتنهایی Decision نیست.
آیا JMeter ظرفیت Production را تضمین میکند؟
خیر. نتیجه فقط برای Build، Environment، Workload، Data، Topology و بازهٔ آزمودهشده Evidence میدهد. رفتار واقعی، تغییرات آینده، وابستگیها و رخدادهای خارج از Scope همچنان عدمقطعیت دارند.
جمعبندی: JMX سبز را با Evidence معتبر اشتباه نگیرید
ارزش JMeter در توان تولید و ثبت Sample است؛ اعتبار تصمیم از قراردادها میآید. Permission، سؤال، Workload، Journey، Data، Session و Oracle را پیش از Thread Group ببندید. JMeter/Java/Plugin/JMX/Property را Pin کنید، CLI اجرا کنید، Generator و Target را همزمان ببینید، JTL را ممیزی و Error/Retry/Timeout را شفاف نگه دارید.
گزارش خوب نمیگوید «سامانه دههزار کاربر را تضمین میکند». میگوید در کدام Profile، Build، Environment و Runهای معتبر چه چیزی مشاهده شد، کجا Generator یا داده محدود بود، چه Faultهایی دیده شدند، چه تصمیم محدودی مجاز است و چه زمانی Evidence منقضی یا نیازمند تکرار میشود.
