مقایسه k۶ و Gatling با JMeter؛ انتخاب و اجرای تست بار

آخرین بازبینی فنی: مرداد ۱۴۰۵

تیمی را تصور کنید که فقط چون توسعه‌دهندگانش JavaScript بلدند، k6 را انتخاب می‌کند؛ دو هفته بعد می‌فهمد سامانه قدیمی‌اش به پروتکلی نیاز دارد که در هسته ابزار نیست. تیم دیگری Gatling را کنار می‌گذارد چون «باید Scala یاد بگیریم»، در حالی که نسخه فعلی Gatling برای Java، Kotlin، Scala، JavaScript و TypeScript کیت توسعه دارد. مسئله این نیست که k6 بهتر است یا Gatling؛ مسئله این است که کدام ابزار، بار واقعی سامانه شما را با هزینه قابل‌قبول و نتیجه قابل‌اعتماد بازتولید می‌کند.

این راهنما یک مقایسه عملی k6 و Gatling با JMeter است. ابتدا حکم سریع را می‌بینید، سپس مدل بار، پروتکل، زبان، گزارش، CI/CD، مقیاس، هزینه و محدودیت‌های ایران را بررسی می‌کنیم. در پایان نیز دو اسکریپت JavaScript هم‌ارز و یک PoC هفت‌روزه دارید تا تصمیم را با داده بگیرید، نه با شهرت ابزار.

حکم سریع: k6، Gatling یا JMeter؟

این جدول «برنده مطلق» اعلام نمی‌کند. برای طراحی بار، شاخص‌ها و توقف امن، ابتدا راهنمای برنامه تست عملکرد را بخوانید؛ ابزار تنها مجری قرارداد آزمون است.

این مقایسه دقیقاً به چه پرسشی پاسخ می‌دهد؟

قصد جست‌وجوی اصلی

کاربر می‌خواهد برای تست بار و Performance Engineering بین k6، Gatling و JMeter انتخاب کند، تفاوت‌های واقعی را بفهمد و بداند هر گزینه در پروژه و CI/CD چگونه اجرا می‌شود. بنابراین صرفاً فهرست مزایا و معایب کافی نیست؛ نتیجه باید به تصمیم، نمونه اجرا و معیار PoC برسد.

نقشه کلیدواژه طبیعی

• کلیدواژه اصلی: مقایسه k6 و Gatling
• کلیدواژه‌های فرعی: جایگزین JMeter، ابزار تست عملکرد، ابزار تست بار، k6 یا Gatling، گتلینگ و جی‌متر
• عبارت‌های بلند: بهترین ابزار تست بار برای CI/CD چیست، k6 بهتر است یا Gatling، مقایسه k6 و JMeter، آموزش اجرای تست بار با JavaScript

پیش از مقایسه ابزار، سه مفهوم را درست کنیم

تست بار با همه تست‌های عملکرد یکی نیست

Load Test رفتار سامانه را زیر بار موردانتظار بررسی می‌کند؛ Stress مرز شکست و الگوی افت را می‌سنجد؛ Spike جهش ناگهانی و Soak فرسایش در زمان را آشکار می‌کند. یک ابزار می‌تواند همه این الگوها را اجرا کند، اما اگر Journey، داده، نرخ ورود، زمان فکر و SLO واقعی نباشد، خروجی دقیق ابزار هم پاسخ مسئله کسب‌وکار نیست.

مدل Open و Closed؛ مهم‌تر از تعداد VU

در مدل Closed تعداد کاربران هم‌زمان را کنترل می‌کنید و شروع iteration بعدی به پایان قبلی وابسته است. در مدل Open نرخ ورود مستقل از زمان پاسخ تعیین می‌شود. اغلب وب‌سایت‌ها در لحظه اوج به مدل Open نزدیک‌اند: کندشدن سرور باعث نمی‌شود مشتریان جدید خودبه‌خود ناپدید شوند. مستندات رسمی هر دو ابزار بر انتخاب درست این مدل تأکید دارند: Open/Closed در k6 و Workload Models در Gatling.

خطای رایج این است که «۱۰۰ کاربر» را از داشبورد تحلیلی برداریم و همان را به VU تبدیل کنیم. ابتدا نرخ ورود Journey، مدت Journey، نسبت مسیرها و رفتار انتظار را از داده تولید استخراج کنید. سپس مدل را در ابزار پیاده کنید.

Check با معیار قبولی یکی نیست

Check می‌گوید پاسخ همان چیزی است که انتظار داشتیم؛ مثلاً وضعیت ۲۰۰ و شناسه سفارش معتبر است. Threshold یا Assertion می‌گوید کل اجرا قرارداد عملکرد را رعایت کرده؛ مثلاً خطا کمتر از ۱٪ و p95 مسیر پرداخت کمتر از ۸۰۰ میلی‌ثانیه است. تستی که فقط latency را می‌سنجد ممکن است صفحه خطای سریع را موفق اعلام کند. تستی که فقط status را چک می‌کند نیز کندی غیرقابل‌قبول را نادیده می‌گیرد.

ابزار پروتکل، مرورگر واقعی نیست

k6 و Gatling عمدتاً ترافیک پروتکل را با هزینه‌ای بسیار کمتر از مرورگر شبیه‌سازی می‌کنند. k6 یک Browser API هم دارد، اما نباید هزاران مرورگر را بی‌دلیل جایگزین بار HTTP کرد. برای وب، ترکیب منطقی معمولاً چنین است: بیشتر بار در سطح پروتکل و تعداد کمی Journey مرورگری برای Core Web Vitals و رفتار رابط. برای صحت API و قراردادها نیز راهنمای جامع تست API مکمل این مقاله است.

وضعیت فعلی ابزارها؛ دو تصور قدیمی را کنار بگذارید

k6 فقط یک CLI بدون ضبط نیست

مستندات رسمی Grafana k6 آن را ابزار متن‌باز، توسعه‌دهنده‌محور و توسعه‌پذیر معرفی می‌کند. علاوه بر HTTP، WebSocket و gRPC، سناریوهای Open/Closed، Threshold، خروجی‌های متعدد، Browser API و Extension دارد. k6 Studio نیز می‌تواند از ضبط مرورگر اسکریپت پروتکل یا Browser بسازد. پس عبارت قدیمی «k6 هیچ رابط یا Recorder ندارد» دیگر دقیق نیست؛ تفاوت این است که هسته گردش‌کار همچنان Test as Code و CLI-first است.

Gatling فقط Scala و Akka نیست

مستندات فعلی Gatling SDKهای Java، Kotlin، Scala، JavaScript و TypeScript را فهرست می‌کند و معماری موتور را ناهمگام توضیح می‌دهد. بنابراین تیم JavaScript برای ارزیابی Gatling مجبور به یادگیری Scala نیست. موتور همچنان روی JVM اجرا می‌شود و JavaScript/TypeScript به زنجیره ابزار و runtime مخصوص Gatling نیاز دارد؛ این وابستگی باید در PoC و محیط محدود سازمان سنجیده شود.

JMeter فقط یک GUI سنگین نیست

GUI برای ساخت و Debug کردن Test Plan مفید است، اما خود پروژه Apache صریحاً می‌گوید تست بار را در CLI اجرا کنید. راهنمای رسمی JMeter ساخت در GUI و اجرا با jmeter -n را از هم جدا می‌کند. بنابراین مقایسه منصفانه، k6 CLI و Gatling CLI را با JMeter GUI زیر بار نمی‌سنجد.

جدول جامع مقایسه k6، Gatling و JMeter

هشدار: عدد «حداکثر VU» معیار خرید نیست. ظرفیت به Journey، زمان پاسخ، TLS، اندازه Payload، Cardinality متریک، منابع مولد و شبکه بستگی دارد. هر ادعای ظرفیت باید روی سخت‌افزار و سناریوی خودتان بازتولید شود.

k6 چه زمانی انتخاب خوبی است؟

نقاط قوت واقعی k6

• اسکریپت خوانا برای تیمی که با JavaScript و گردش‌کار Git آشناست؛
• Scenario و Executor صریح برای نرخ ورود یا VU؛
• Thresholdهای نزدیک به SLO و مناسب گیت CI؛
• Metric، Tag و Submetric برای جداکردن endpoint و Journey؛
• خروجی به سامانه‌های مشاهده‌پذیری و امکان توسعه با Extension؛
• ترکیب بار پروتکل با تعداد محدود سناریوی مرورگری.

محدودیت‌هایی که باید در PoC بسنجید

• JavaScript در k6 معادل Node.js کامل نیست؛ قبل از استفاده از packageها و APIهای runtime، سازگاری را بررسی کنید.
• پروتکل خارج از هسته ممکن است Extension بخواهد؛ مالکیت، نسخه، امنیت زنجیره تأمین و سازگاری آن هزینه عملیاتی است.
• خلاصه CLI برای تحلیل تیمی بلندمدت کافی نیست؛ نگهداری Dashboard، Backend متریک یا سرویس ابری بخشی از راهکار است.
• در Arrival Rate، کمبود VU تخصیص‌یافته می‌تواند dropped_iterations بسازد؛ آن را شکست ظرفیت مولد یا سامانه تفسیر کنید، نه نادیده بگیرید.

نصب و اجرای حداقلی k6

صفحه نصب رسمی k6 بسته‌های Linux، macOS، Windows، Docker و k6 Studio را پوشش می‌دهد. برای نمونه زیر:

# پس از نصب رسمی
k6 version
BASE_URL=https://staging.example.com k6 run catalog.js

هدف را از Environment Variable می‌گیریم تا URL تولید داخل کد Commit نشود. تست بار بدون مجوز را هرگز علیه سایت عمومی یا Production اجرا نکنید.

نمونه k6: نرخ ورود ثابت با Check و Threshold

import http from 'k6/http';
import { check } from 'k6';

const BASE_URL = __ENV.BASE_URL || 'https://staging.example.com';

export const options = {
  scenarios: {
    catalog: {
      executor: 'constant-arrival-rate',
      rate: 5,
      timeUnit: '1s',
      duration: '2m',
      preAllocatedVUs: 20,
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{name:catalog}': ['p(95)<500'],
    checks: ['rate>0.99'],
    dropped_iterations: ['count==0'],
  },
};

export default function () {
  const response = http.get(`${BASE_URL}/api/products`, {
    tags: { name: 'catalog' },
  });

  check(response, {
    'status is 200': (r) => r.status === 200,
    'body is not empty': (r) => Boolean(r.body),
  });
}

در این نمونه، پنج iteration در ثانیه مستقل از طول پاسخ شروع می‌شود. preAllocatedVUs ظرفیت اولیه مجری است، نه هدف بار. طبق راهنمای Thresholdهای k6، شکست معیار باعث وضعیت ناموفق و کد خروج غیرصفر می‌شود؛ پس Pipeline می‌تواند بر اساس قرارداد واقعی تصمیم بگیرد.

خروجی k6 را چگونه بخوانیم؟

• http_req_duration را با p95/p99 هر Journey بخوانید، نه فقط Average کل.
• http_req_failed خطای HTTP موردانتظار را نشان می‌دهد؛ Check محتوایی را نیز جدا ببینید.
• dropped_iterations در مدل Arrival Rate هشدار می‌دهد که نرخ هدف اجرا نشده است.
• CPU، RAM، Network و Open File مولد بار را کنار Metricهای سامانه مقصد ثبت کنید.
• Tagهای پرکاردینال مانند شناسه کاربر یا سفارش را به Metric اضافه نکنید.

Gatling چه زمانی انتخاب خوبی است؟

نقاط قوت واقعی Gatling

• SDKهای چندزبانه و سناریوهای کدمحور قابل نسخه‌بندی؛
• Injection Profile صریح برای Open و Closed Workload؛
• Checks برای اعتبار پاسخ و Assertions برای قبولی کل اجرا؛
• گزارش HTML استاتیک پیش‌فرض در نسخه Community؛
• هم‌خوانی خوب با پروژه‌های Java/JVM و ابزارهای Maven، Gradle و sbt؛
• مسیر JavaScript/TypeScript با npm برای تیم‌های وب.

محدودیت‌هایی که باید در PoC بسنجید

• همه SDKها الزاماً در هر قابلیت و هر زمان برابری کامل ندارند؛ ماتریس پروتکل و قابلیت نسخه مورد استفاده را بخوانید.
• JavaScript SDK روی موتور Gatling اجرا می‌شود و Node.js API دلخواه را نمی‌توان بدون بررسی وارد سناریو کرد.
• گزارش استاتیک برای Trend سازمانی، مقایسه اجراها و مدیریت توزیع‌شده کافی نیست؛ این نیازها هزینه زیرساخت یا Enterprise ایجاد می‌کنند.
• تیم باید نسخه SDK، runtime و lockfile را Pin کند؛ «آخرین نسخه» بدون کنترل، بازتولیدپذیری را از بین می‌برد.

نصب و اجرای حداقلی Gatling با JavaScript

راهنمای نصب Gatling مسیرهای Java، Kotlin، Scala، JavaScript و TypeScript را جدا توضیح می‌دهد. برای پروژه JS، از Starter رسمی یا dependencyهای رسمی و lockfile استفاده کنید:

npm install
npx gatling run --simulation catalogSimulation \
  baseUrl=https://staging.example.com

نسخه Node/npm و SDK را از مستندات همان نسخه بگیرید و در CI Pin کنید. اگر دسترسی شبکه سازمان محدود است، دانلود runtime و packageها را پیش از انتخاب نهایی آزمایش کنید.

نمونه Gatling: همان نرخ و همان معیار با JavaScript

import {
  constantUsersPerSec,
  getParameter,
  global,
  scenario,
  simulation,
} from '@gatling.io/core';
import { http, status } from '@gatling.io/http';

export default simulation((setUp) => {
  const baseUrl = getParameter(
    'baseUrl',
    'https://staging.example.com'
  );

  const httpProtocol = http
    .baseUrl(baseUrl)
    .acceptHeader('application/json');

  const catalog = scenario('Catalog').exec(
    http('catalog')
      .get('/api/products')
      .check(status().is(200))
  );

  setUp(
    catalog.injectOpen(constantUsersPerSec(5).during(120))
  )
    .protocols(httpProtocol)
    .assertions(
      global().failedRequests().percent().lt(1),
      global().responseTime().percentile(95).lt(500)
    );
});

این کد عمداً همان پنج کاربر ورودی در ثانیه، دو دقیقه و p95 زیر ۵۰۰ میلی‌ثانیه را هدف می‌گیرد. صفحه رسمی Assertions در Gatling توضیح می‌دهد که شکست هر Assertion کل Simulation را ناموفق می‌کند. برای برابری دقیق‌تر با k6، یک معیار جدا برای نرخ Check و ظرفیت مولد نیز در چارچوب PoC ثبت کنید.

گزارش Gatling را چگونه بخوانیم؟

• گزارش HTML را Artifact اجرای CI کنید و همراه Commit، محیط و نسخه سناریو نگه دارید.
• Global p95 به‌تنهایی کافی نیست؛ Request و Group بحرانی را جدا Assert کنید.
• Errorها را بر اساس نوع و زمان با Log سرویس، Trace و Metric زیرساخت هم‌بسته کنید.
• نرخ هدف، نرخ اجراشده و ظرفیت Load Generator را مقایسه کنید.
• Warm-up، Ramp و پنجره اندازه‌گیری را در گزارش و قرارداد آزمون ثبت کنید.

JMeter هنوز کجا انتخاب درست است؟

دلایل موجه برای ماندن روی JMeter

• صدها Test Plan معتبر، داده و Component سفارشی دارید و هزینه مهاجرت بازگشت روشنی ندارد.
• پروتکل یا Sampler مشخصی در JMeter پایدار است و جایگزین جدید نیازمند Extension پرریسک است.
• Recorder و GUI برای ورود کارشناسان دامنه ارزش دارد و تیم قواعد نگهداری JMX را حل کرده است.
• اجرای CLI، Version Control، گزارش JTL و ظرفیت مولد در عمل قابل‌اعتمادند.

نشانه‌های منطقی برای PoC مهاجرت

• Merge Conflict و Review فایل XML، تغییر کوچک را پرهزینه کرده است.
• افزونه‌های بدون مالک یا ناسازگاری نسخه، اجرای بازتولیدپذیر را مختل می‌کند.
• ساخت گیت SLO و خروجی Observability نیازمند Glue Code شکننده شده است.
• تیم محصول و توسعه نمی‌تواند Scenario را بفهمد یا مشارکت کند.
• مولد JMeter با Plan فعلی پیش از سامانه مقصد اشباع می‌شود و بهینه‌سازی/توزیع هم مسئله را اقتصادی حل نمی‌کند.

برای یادگیری ساخت و اجرای صحیح، آموزش تست عملکرد با JMeter را ببینید. همچنین Best Practices رسمی JMeter اجرای CLI، Listener کم، CSV و اندازه‌گیری ظرفیت مولد را توصیه می‌کند.

۱۲ معیار انتخاب ابزار تست عملکرد

۱. قابلیت مدل‌کردن بار واقعی

آیا ابزار نرخ ورود، VU ثابت، Ramp، چند Scenario هم‌زمان، داده منحصربه‌فرد و زمان فکر را بدون دورزدن‌های شکننده پیاده می‌کند؟ یک نمونه واقعی از Production را انتخاب کنید، نه Hello World.

۲. پروتکل و رفتار لازم

فهرست «پشتیبانی می‌شود» کافی نیست. Authentication، TLS/mTLS، Proxy، Streaming، Correlation، Payload، Compression و Extension موردنیاز را اجرا کنید. رسمی یا Community بودن و کیفیت نگهداری را ثبت کنید.

۳. زبان و مالکیت تیم

زبان آشنا شروع را آسان می‌کند، اما مالکیت مهم‌تر است: چه کسی Code Review، Debug، Upgrade و Incident را انجام می‌دهد؟ اگر فقط یک متخصص سناریوها را می‌فهمد، ابزار محبوب هم Bus Factor یک دارد.

۴. Check، Correlation و داده

مسیر Login→Search→Cart→Payment باید Token و شناسه‌های پویا را استخراج کند، پاسخ معنایی را بسنجد و داده هر کاربر را ایزوله کند. کشیدن بار روی یک محصول ثابت یا یک حساب مشترک، Cache/Lock غیرواقعی می‌سازد.

۵. Threshold و گیت CI

ابزار باید قرارداد p95/p99، Error Rate، Goodput و Check را به Exit Code یا نتیجه ماشین‌خوان تبدیل کند. گیت را روی محیط مشترک پرنوسان سخت نکنید؛ نتیجه می‌تواند Pass، Fail، Inconclusive یا Infra Error باشد.

۶. گزارش و تحلیل روند

برای اجرای محلی، HTML یا CLI کافی است؛ برای تصمیم ظرفیت، تاریخچه قابل‌مقایسه، Annotation انتشار، Dashboard و هم‌بستگی با Trace لازم می‌شود. هزینه ذخیره و Cardinality را وارد TCO کنید.

۷. بازده و ظرفیت مولد بار

با System Under Test سریع یا Stub شروع کنید و سقف مولد را بسنجید. CPU، RAM، Network، Socket، GC/runtime و Clock را ثبت کنید. وقتی مولد اشباع است، افزایش VU به معنای افزایش بار معتبر نیست.

۸. توزیع جغرافیایی و Orchestration

اگر کاربر ایران، اروپا و چند شبکه دارد، محل مولد روی latency اثر می‌گذارد. اجرای توزیع‌شده به هم‌زمانی ساعت، تجمیع نتیجه، Secret، Health، Cleanup و محدودکردن Blast Radius نیاز دارد؛ صرفاً بالا آوردن چند Pod کافی نیست.

۹. نگهداری و Upgrade

یک تغییر API، چرخش Token و ارتقای نسخه ابزار را در PoC انجام دهید. زمان تغییر، شکست dependency و کیفیت خطاها را بسنجید. محیط تست بازتولیدپذیر با Docker می‌تواند runtime و dependency مولد را ثابت نگه دارد.

۱۰. امنیت و حریم خصوصی

Secret در کد یا گزارش نباشد؛ داده واقعی مشتری را به سرویس ابری نفرستید؛ Token کم‌اختیار و کوتاه‌عمر باشد؛ و هدف تست Allowlist شود. Extension، Image و packageهای مولد نیز بخشی از زنجیره تأمین‌اند.

۱۱. هزینه کل مالکیت

TCO برابر قیمت License نیست: زمان اسکریپت‌نویسی، آموزش، Runner، Cloud egress، نگهداری Dashboard، Upgrade، گزارش، پشتیبانی و زمان تحلیل را جمع کنید. گزینه متن‌باز می‌تواند به‌سبب عملیات پرهزینه‌تر، گران‌تر تمام شود.

۱۲. دسترسی و دوام در ایران

امکان نصب از Mirror قانونی سازمان، دسترسی پایدار به Registry/Cloud، پرداخت، پشتیبانی، محل داده و سناریوی خروج را بررسی کنید. انتخابی که فقط با حساب شخصی یا IP خاص کار می‌کند، برای عملیات سازمانی آماده نیست.

PoC هفت‌روزه برای انتخاب قابل دفاع

روز ۱: قرارداد واحد آزمون

• یک Journey بحرانی، مثلاً Browse→Cart→Checkout، انتخاب کنید.
• نرخ ورود واقعی، مدت، Ramp و نسبت مسیرها را از داده تولید بگیرید.
• SLO را بنویسید: p95 هر مسیر، نرخ خطا، Goodput و توقف ایمن.
• محیط، Build، داده، dependency و پنجره آزمون را Freeze کنید.

روز ۲ و ۳: ساخت دو سناریوی هم‌ارز

همان Check، Correlation، داده و Load Profile را در دو ابزار پیاده کنید. زمان نفر، خطوط سفارشی، خطاهای نصب و نقطه‌های مبهم را ثبت کنید. Record-and-playback بدون پاک‌سازی درخواست‌های اضافی، PoC معتبر نیست.

روز ۴: اعتبارسنجی مولد

ابتدا Smoke، سپس Step Load اجرا کنید. مولد باید نرخ هدف را بدون CPU/Network/GC غیرعادی بسازد. اگر یکی روی لپ‌تاپ و دیگری روی Runner قوی اجرا شود، مقایسه باطل است.

روز ۵: اتصال به CI و Observability

Pipeline باید نسخه ابزار، Commit، Build و محیط را ثبت کند؛ Secret را تزریق کند؛ Report و Raw Result را Artifact کند؛ و بر اساس Threshold نتیجه بدهد. الگوی کامل‌تر را در آموزش CI/CD تست خودکار ببینید.

روز ۶: تمرین شکست

یک latency کنترل‌شده، پاسخ ۵۰۰ و قطع dependency تزریق کنید. آیا ابزار خطای معنایی را می‌بیند؟ آیا گزارش علت را پیدا می‌کند؟ آیا Stop Condition از فشار بیشتر جلوگیری می‌کند؟ ابزاری که فقط در روز آفتابی خوب است، انتخاب عملیاتی خوبی نیست.

روز ۷: امتیاز و تصمیم

امتیاز وزنی راهنمای گفت‌وگوست، نه حقیقت ریاضی. هر معیار Must-have که رد شود، انتخاب را مستقل از مجموع امتیاز ابطال می‌کند.

انتخاب بر اساس سناریوی تیم

تیم Node.js و API با Pipeline سریع

k6 را نخست PoC کنید، چون اصطکاک نوشتن Scenario و Threshold پایین است. اما Gatling JS/TS را نیز با همان کد و گزارش HTML بسنجید؛ تفاوت امروز کمتر از مقایسه‌های قدیمی است. اگر نیاز گزارش استاتیک آماده و مدل عملیاتی Gatling برایتان مهم‌تر بود، نتیجه می‌تواند برعکس شود.

تیم Java/Kotlin با Maven یا Gradle

Gatling مسیر طبیعی‌تری برای هم‌زیستی با Build و IDE دارد. این به معنی برتری خودکار موتور نیست؛ ظرفیت مولد، پروتکل، Assertion و هزینه Enterprise را همچنان بسنجید. k6 می‌تواند ابزار مستقل و ساده‌ای برای SRE/Platform باشد.

سامانه بانکی یا قدیمی با پروتکل خاص

ابتدا ماتریس پروتکل و Extension را بررسی کنید. اگر JMeter دارایی پایدار دارد، بازنویسی همه چیز برای زیبایی کد توجیه ندارد. یک Adapter یا حفظ JMeter برای آن دامنه و استفاده از ابزار جدید برای HTTP مدرن، راهبرد چندابزاری معقولی است.

نیاز هم‌زمان به بار API و تجربه مرورگر

k6 گزینه Hybrid جذابی دارد: هزاران درخواست پروتکلی و تعداد کم VU مرورگری. با این حال، اگر هدف اصلی Functional UI یا سازگاری مرورگر است، ابزار E2E تخصصی را جدا نگه دارید. بار مرورگر پرهزینه‌تر است و نباید جای مدل پروتکل را بگیرد.

بار بزرگ یا چند منطقه‌ای

نسخه Cloud/Enterprise و Orchestration را روی هزینه، محل مولد، اقامت داده، Network و خروج از Vendor بسنجید. برای معماری محیط و PoC ارائه‌دهنده، راهنمای تست ابری در AWS، Azure و GCP مفید است.

الگوی درست اجرای تست عملکرد در CI/CD

سه Lane به‌جای یک تست غول‌پیکر

• Commit lane: Smoke کوتاه، Checkهای عملکردی، بار کم و بودجه چند دقیقه؛
• Nightly lane: Load متوسط روی محیط پایدار با Trend؛
• Release/capacity lane: بار نماینده، پنجره رزروشده، مشاهده‌پذیری کامل و مجوز صریح.

این تفکیک با رویکرد Shift-left مبتنی بر شواهد زودهنگام سازگار است: بازخورد ارزان را زود می‌گیریم، اما آزمون گران و پرریسک را بی‌محابا روی هر Commit اجرا نمی‌کنیم.

قرارداد Pipeline

1. Build و محیط سالم و قابل‌شناسایی باشد.
2. نسخه ابزار، SDK، Script و داده Pin شده باشد.
3. Preflight اتصال، مجوز و ظرفیت مولد اجرا شود.
4. تست با Timeout و Stop Condition محدود شود.
5. نتیجه خام، گزارش، Log و Manifest همیشه منتشر شود.
6. Threshold نتیجه را Pass/Fail کند؛ اختلال زیرساخت به‌عنوان Infra Error جدا بماند.
7. محیط و داده در پایان Cleanup شوند.

چرا Benchmark روی Runner مشترک خطرناک است؟

همسایه پرمصرف، Autoscaling، Cache، Network و Build متفاوت می‌توانند تغییر p95 بسازند. برای گیت حساس، Runner و محیط کنترل‌شده یا Baseline آماری لازم است. Flaky Performance Gate را با Retry کور پنهان نکنید؛ ابتدا Noise را مدل و نتیجه مشکوک را Inconclusive کنید.

بدون مشاهده‌پذیری، تست بار فقط اعلام درد است

چه چیزهایی را هم‌بسته کنیم؟

• p95/p99 و Error هر Journey با CPU، Memory، GC، Thread/Event Loop و Connection Pool؛
• نرخ درخواست با Queue Depth، Saturation و Retry؛
• خطای کاربر با Trace و Log همان بازه؛
• نسخه Build، Feature Flag، Config و Dataset با Run ID؛
• Metric مولد بار با Metric سامانه مقصد.

Goodput را کنار Throughput ببینید

Throughput ممکن است شامل پاسخ‌های سریع اما ناموفق باشد. Goodput تعداد تراکنش‌هایی است که هم از Check عملکردی عبور کرده‌اند و هم SLO زمانی را رعایت کرده‌اند. برای ظرفیت کسب‌وکار، «سفارش موفق در ثانیه زیر ۸۰۰ms» مفیدتر از «درخواست در ثانیه» است.

نکات اجرایی برای تیم‌های ایرانی

شبکه و محل مولد

مولد داخل کشور، خارج کشور و داخل دیتاسنتر نتیجه‌های متفاوت می‌دهد. هدف تست را مشخص کنید: ظرفیت Backend، تجربه کاربر ایران یا رفتار CDN. DNS، Proxy، فیلترینگ، Packet Loss و مسیر بین‌الملل را در Run Manifest ثبت کنید.

تحریم، Registry و سرویس ابری

پیش از وابستگی به Cloud، مسیر قانونی خرید و تمدید، MFA، بازیابی حساب، Export داده و اجرای Self-hosted را آزمایش کنید. package، Docker image و runtime لازم را در Registry تأییدشده سازمان Mirror کنید و برای روز قطع دسترسی Runbook داشته باشید.

داده و حریم خصوصی

شماره موبایل، کد ملی، Token پرداخت و داده سفارش واقعی نباید وارد Script، CSV، Log یا Cloud خارجی شود. داده مصنوعی سازگار با قواعد دامنه بسازید؛ پاسخ‌ها را Mask کنید؛ و Retention گزارش را محدود نگه دارید.

پرداخت و سرویس‌های ثالث

درگاه پرداخت، پیامک و سرویس دولتی را بدون هماهنگی زیر بار نبرید. Sandbox، Stub یا Virtual Service بسازید و ظرفیت dependency واقعی را در آزمون جدا و مجاز بسنجید. هزینه پیامک یا تراکنش نیز Stop Condition لازم دارد.

خطاهای رایج در مقایسه k6، Gatling و JMeter

• Benchmark اینترنتی به‌جای PoC: سناریو و سخت‌افزار نویسنده با شما یکسان نیست.
• مقایسه GUI با CLI: اجرای JMeter GUI زیر بار نتیجه را از ابتدا منحرف می‌کند.
• تبدیل مستقیم Concurrent User به Arrival Rate: مدل کسب‌وکار و زمان Journey نادیده می‌ماند.
• فقط Average: Tail Latency و تجربه بد بخش کوچکی از کاربران پنهان می‌شود.
• فقط status ۲۰۰: صفحه خطا یا پاسخ تهی می‌تواند سریع و ظاهراً موفق باشد.
• یک حساب و یک رکورد: Cache، Lock و محدودیت داده نتیجه را غیرواقعی می‌کند.
• افزایش VU تا سقوط: بدون Stop Condition ممکن است Production یا dependency را آسیب بزند.
• نادیده‌گرفتن مولد: اشباع Runner به‌اشتباه گلوگاه Backend تفسیر می‌شود.
• خرید Cloud پیش از Exit Test: داده، Script و گزارش ممکن است قابل انتقال نباشند.
• انتخاب بر اساس آینده‌نگری ابزار: Trend جذاب جای نیاز و شاهد امروز را نمی‌گیرد؛ برای ارزیابی روندها به رادار آینده QA رجوع کنید.

درخت تصمیم یک‌دقیقه‌ای

1. پروتکل حیاتی فقط در یکی پایدار است؟ همان گزینه وارد PoC می‌شود؛ اگر هیچ‌کدام نیست، JMeter/Extension/ابزار تخصصی را بررسی کنید.
2. دارایی JMeter معتبر و هزینه نگهداری قابل‌قبول است؟ ابتدا بهینه‌سازی و CLI؛ مهاجرت فقط با منفعت اندازه‌گیری‌شده.
3. تیم JS/TS و تمرکز API/CI دارد؟ k6 و Gatling JS را با سناریوی هم‌ارز بسنجید.
4. تیم JVM و گزارش HTML محلی مهم است؟ Gatling را نخست PoC کنید.
5. Browser Performance لازم است؟ k6 Hybrid را بررسی کنید، اما بار اصلی را پروتکلی نگه دارید.
6. اجرای توزیع‌شده و تاریخچه سازمانی لازم است؟ Orchestration، Cloud/Enterprise، هزینه و اقامت داده را جدا امتیاز دهید.
7. هیچ Must-have رد نشده؟ نتیجه PoC وزنی و مالکیت تیم تصمیم نهایی را می‌سازد.

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

• Journey و مدل Open/Closed از داده واقعی استخراج شده است.
• Check عملکردی و SLO زمانی هر دو تعریف شده‌اند.
• پروتکل، Auth، TLS، Correlation و داده در PoC اجرا شده‌اند.
• دو ابزار روی Build، محیط، مولد و Load Profile یکسان سنجیده شده‌اند.
• ظرفیت Load Generator و dropped_iterations/معادل آن کنترل شده است.
• گزارش، Raw Result، Manifest و Observability قابل پیوندند.
• گیت CI، Timeout، Stop Condition و Infra Error طراحی شده‌اند.
• نسخه، lockfile، Image و Extensionها Pin و اسکن می‌شوند.
• TCO سه‌ساله، آموزش، Cloud، Storage و عملیات محاسبه شده است.
• دسترسی ایران، حریم خصوصی، پرداخت و Exit Plan آزموده شده‌اند.
• مالک مشخصی برای Script، Upgrade، Dashboard و Incident وجود دارد.

جمع‌بندی: ابزار را با شاهد انتخاب کنید

k6 برای بسیاری از تیم‌های API و CI انتخابی سریع و شفاف است؛ Gatling با SDKهای پنج‌زبانه، مدل بار قدرتمند و گزارش HTML آماده، دیگر ابزار «فقط Scala» نیست؛ و JMeter در سازمانی با دارایی JMX و پروتکل‌های خاص هنوز می‌تواند اقتصادی‌ترین انتخاب باشد. هیچ‌کدام به‌خودی‌خود تست دقیق، ارزان یا مقیاس‌پذیر را تضمین نمی‌کنند.

تصمیم حرفه‌ای از این مسیر می‌آید: Journey واقعی → مدل بار درست → Check و SLO → PoC هم‌ارز → اعتبار مولد → CI و Observability → TCO و محدودیت عملیاتی. اگر یکی از این حلقه‌ها حذف شود، نام ابزار فقط حس اطمینان می‌دهد، نه شواهد عملکرد.

سوالات متداول

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

برنده عمومی وجود ندارد. k6 برای گردش‌کار CLI، API، Threshold و تیم‌های JS/TS بسیار روان است. Gatling برای SDKهای Java/JVM و JS/TS، Injection Profile و گزارش HTML آماده مزیت دارد. پروتکل، مدل بار، نگهداری، گزارش و ظرفیت مولد را با PoC هم‌ارز بسنجید.

آیا k6 یا Gatling جایگزین کامل JMeter هستند؟

برای HTTP/API مدرن در بسیاری از پروژه‌ها بله، اما «کامل» به نیاز شما بستگی دارد. اگر Sampler، افزونه یا دارایی JMX مشخصی حیاتی است، مهاجرت ممکن است پرهزینه یا ناقص باشد. می‌توانید راهبرد چندابزاری داشته باشید و هر دامنه را با مناسب‌ترین ابزار اجرا کنید.

برای Gatling باید Scala یاد بگیریم؟

خیر. مستندات فعلی Gatling از Java، Kotlin، Scala، JavaScript و TypeScript پشتیبانی می‌کند. زبان آشنای تیم را انتخاب کنید و بررسی کنید قابلیت پروتکل موردنیاز در همان SDK موجود است. Runtime و زنجیره build Gatling همچنان باید در محیط شما اعتبارسنجی شود.

کدام ابزار کاربران مجازی بیشتری می‌سازد؟

بدون سناریو و سخت‌افزار مشخص، این پرسش پاسخ معتبری ندارد. TLS، Payload، زمان پاسخ، Check، Metric، شبکه و منابع مولد ظرفیت را تغییر می‌دهند. روی مولد یکسان، Journey یکسان و نرخ هدف یکسان Benchmark کنید و اشباع مولد را هم اندازه بگیرید.

برای CI/CD کدام ابزار مناسب‌تر است؟

هر سه می‌توانند در CI اجرا شوند. k6 Threshold و CLI مستقیمی دارد؛ Gatling Assertions و plugin/CLIهای build ارائه می‌کند؛ JMeter نیز CLI و گزارش JTL/HTML دارد. گزینه مناسب ابزاری است که نتیجه ماشین‌خوان، زمان اجرای قابل‌قبول، Artifact قابل‌ردیابی و نگهداری پایدار برای تیم شما فراهم کند.

منابع رسمی و تاریخ‌پذیر

• مستندات رسمی Grafana k6
• مدل Open و Closed در k6
• Thresholdها در k6
• نصب k6 و k6 Studio
• مستندات رسمی Gatling
• نصب و زبان‌های پشتیبانی‌شده Gatling
• مدل بار در Gatling
• Assertions در Gatling
• Best Practices رسمی Apache JMeter