تست بار سایت با k6 قبل از کمپین فروش

اگر تست بار سایت را پیش از کمپین فروش انجام ندهید، اولین آزمون ظرفیت فروشگاه را خریدارانی برگزار می‌کنند که با کد تخفیف آمده‌اند. راه کم‌هزینه‌تر: دو هفته مانده، با ابزار متن‌باز k6 مسیر خرید را روی سایت خودتان شبیه‌سازی کنید و تا شب قبل گلوگاه را رفع کنید.

شمارش معکوس در پنج خط

• ✅ چهارده روز مانده (D-14): مجوز آزمون، خبر به میزبان، عدد هدف
• ✅ هفت روز مانده (D-7): نصب k6، قرارداد آستانه‌ها، سناریوی خرید
• ✅ سه روز مانده (D-3): بار پله‌ای، خواندن شاخص‌ها، رفع گلوگاه
• ✅ یک روز مانده (D-1): اجرای دوباره و تصمیم برو یا نرو
• ✅ روز کمپین: k6 خاموش، مانیتورینگ روشن

تاریخ‌های این برنامه فرضی‌اند و اعداد اسکریپت‌ها نمونه؛ با فرصت کمتر فاصله‌ها را فشرده کنید. در تصمیم نهایی فقط خروجی k6 روی سایت خودتان حساب می‌شود.

دو هفته مانده؛ چرا تست بار سایت باید پیش از تبلیغ انجام شود

گلوگاه‌های فروشگاه، از صف پردازه‌های PHP تا سقف اتصال پایگاه داده، معمولاً فقط زیر بار همزمان پیدا می‌شوند. اگر اولین آزمون بعد از شروع تبلیغ باشد، هزینه‌اش را بودجه تبلیغ و خریدار واقعی می‌پردازند؛ دو هفته جا برای یک اصلاح و یک آزمون دوباره می‌گذارد.

مدرسه‌ها مانور زلزله را در روزی آرام برگزار می‌کنند تا معلوم شود کدام راه‌پله گیر می‌کند. آزمون k6 همان راه‌پله را در فروشگاه نشان می‌دهد و هر لحظه می‌توانید متوقفش کنید.

مجوز آزمون و خبر دادن به میزبان

فقط سایتی را آزمون کنید که مالکش هستید یا مجوز کتبی‌اش را دارید. راهنمای آزمون بار وب‌سایت‌ها در مستندات k6 هم می‌گوید سرور دیگران را آزمون نکنید و درخواست‌های سرویس ثالث، از جمله درگاه پرداخت، را بدون اجازه‌شان از سناریو بیرون بگذارید.

بازه ساعت آزمون و IP ماشین k6 را به میزبان بگویید؛ سامانه حفاظتی ممکن است ترافیک ناگهانی یک IP را حمله بداند و محدودش کند و آن وقت عدد شما رفتار فایروال است.

عدد هدف و عدد پایه سرور

در ابزار آمار، شلوغ‌ترین ساعت کمپین قبلی را پیدا کنید و ببینید هر دقیقه چند بازدید تازه شروع شده است. حاصل‌ضرب این عدد در ضریب رشد مورد انتظار، نرخ ورود هدف بر حسب «بازدید در دقیقه» است؛ اسکریپت هفته بعد همین واحد را می‌گیرد.

عدد پایه سرور را هم داشته باشید تا کندی زیر بار را بتوانید به کد سایت یا سخت‌افزار نسبت دهید. همین D-14 این عدد را بگیرید؛ روشش بنچمارک سرور مجازی با YABS و fio است.

یک هفته مانده؛ نصب k6 و نوشتن سناریوی خرید

در روز هفتم، k6 را روی ماشینی جدا از سرور فروشگاه نصب کنید؛ k6 پردازنده و حافظه زیادی مصرف می‌کند و روی همان سرور با سایت رقابت می‌کند.

نصب از مسیر رسمی

طبق صفحه نصب k6، روی اوبونتو و دبیان مخزن رسمی را با کلید امضایش اضافه می‌کنید؛ مسیرهای دیگر در پرسش آخر آمده است.

curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

قرارداد آستانه‌ها، پیش از اولین اجرا

بدون معیار قبولی، هر کس نتیجه تست بار سایت را به سلیقه خودش می‌خواند. در مستندات آستانه‌ها در k6، آستانه عبارتی مثل p(95)<800 روی یک شاخص است و اگر در پایان نادرست باشد، k6 آزمون را رد و با کد خروج غیرصفر تمام می‌کند.

// thresholds.js (D-7, before the first run)
export const CONTRACT = {
  http_req_failed: [
    { threshold: 'rate<0.01' },
    { threshold: 'rate<0.05', abortOnFail: true, delayAbortEval: '30s' },
  ],
  http_req_duration: ['p(95)<800'],
  'http_req_duration{name:cart}': ['p(95)<1500'],
  checks: ['rate>0.99'],
};

قانون اول آزمون را با خطای بیش از یک درصد رد می‌کند. قانون دوم با abortOnFail آزمون را در خطای بالای پنج درصد قطع می‌کند؛ delayAbortEval این داوری را سی ثانیه عقب می‌اندازد. عددها نمونه‌اند.

سناریوی خرید با مدل ورود باز

اسکریپت زیر صفحه اصلی، محصول و سبد را با executor از نوع ramping-arrival-rate باز می‌کند. چون timeUnit روی '1m' است، هر target یعنی تعداد بازدید تازه در دقیقه؛ نرخ هدف روز چهاردهم را بدون تقسیم بر ۶۰ بنویسید. اگر timeUnit را '1s' بگذارید، همان عدد را بر ۶۰ تقسیم کنید.

// campaign.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { CONTRACT } from './thresholds.js';

const BASE = __ENV.BASE_URL;

export const options = {
  thresholds: CONTRACT,
  scenarios: {
    campaign: {
      executor: 'ramping-arrival-rate',
      timeUnit: '1m', // every target = new visits per minute
      preAllocatedVUs: 50,
      maxVUs: 200,
      stages: [
        { target: 300, duration: '3m' },
        { target: 300, duration: '5m' },
        { target: 0, duration: '1m' },
      ],
    },
  },
};

export default function () {
  const home = http.get(`${BASE}/`, { tags: { name: 'home' } });
  check(home, { 'home 200': (r) => r.status === 200 });
  sleep(2 + Math.random() * 3);
  const product = http.get(`${BASE}${__ENV.PRODUCT_PATH}`, { tags: { name: 'product' } });
  check(product, { 'product 200': (r) => r.status === 200 });
  sleep(2 + Math.random() * 3);
  const cart = http.get(`${BASE}${__ENV.CART_PATH}`, { tags: { name: 'cart' } });
  check(cart, { 'cart 200': (r) => r.status === 200 });
}

k6 run --summary-mode=full -e BASE_URL=https://staging.example.com \
  -e PRODUCT_PATH=/product/sample/ -e CART_PATH=/cart/ campaign.js

هر دو فایل را در یک پوشه بگذارید؛ اگر یکی از سه متغیر -e جا بیفتد، نشانی به undefined ختم می‌شود و checkها رد می‌شوند. مستندات k6 برای preAllocatedVUs تقریب «میانه زمان تکرار × نرخ در ثانیه» را می‌دهد: هشت ثانیه × ۵ در ثانیه (۳۰۰ در دقیقه) یعنی حدود ۴۰ کاربر.

در executorهای نرخ ورود، sleep انتهای تکرار لازم نیست. این سناریو بدون کوکی سبد است و صفحه‌های کش‌شده معمولاً سریع‌تر از تجربه خریدار با سبد پر جواب می‌دهند؛ درخواست افزودن به سبد را با k6 Studio از ضبط مرورگر بسازید. اجرای اول (smoke test) را فقط با یک پله یک‌دقیقه‌ای و target برابر ۱ انجام دهید.

سه روز مانده؛ کاربر همزمان را بالا ببرید و گلوگاه را پیدا کنید

سه روز مانده، همان اسکریپت را پله‌پله تا نرخ هدف و کمی بالاتر ببرید. حاصل تست بار سایت در این مرحله یک جمله است: تا فلان نرخ ورود همه آستانه‌ها برقرار ماندند و از آنجا آستانه فلان شاخص رد شد.

در صفحه انواع آزمون k6، spike برای رویدادهای فصلی آمده و stress برای بار بالاتر از میانگین. برای کمپین یک اجرا روی نرخ هدف، یکی بالاتر و یک پرش کوتاه، مثل لحظه ارسال پیامک، انجام دهید.

خواندن خروجی؛ هر شاخص چه می‌گوید

شاخص	چه می‌گوید	اقدام
http_req_failed	نسبت درخواست ناموفق؛ پیش‌فرض، کد خارج از ۲۰۰ تا ۳۹۹	لاگ خطای وب‌سرور و PHP را بخوانید
http_req_duration	زمان کل درخواست، بدون DNS و اتصال	پله‌ای که p(95) در آن رد شد، سقف فعلی است
http_req_waiting	انتظار تا اولین بایت (TTFB)	صف PHP و کوئری‌های کند را ببینید
dropped_iterations	تکرارهای شروع‌نشده به دلیل نبود کاربر مجازی آزاد	دقیقه اول: preAllocatedVUs کم است؛ وسط آزمون همراه رشد http_req_waiting: سایت کند شده
vus	کاربران مجازی فعال	با سقف پردازه‌ها و اتصال‌ها مقایسه کنید

علت را روی سرور، کنار خروجی k6، پیدا کنید

خروجی k6 تجربه کاربر را نشان می‌دهد؛ علت را در CPU، حافظه، پردازه‌های PHP-FPM و اتصال‌های پایگاه داده ببینید. اگر http_req_waiting بالا رفت و CPU جا داشت، معمولاً سقف پردازه‌ها یا اتصال‌ها زودتر پر شده است.

شب قبل و روز کمپین چه کارهایی باقی می‌ماند؟

شب قبل از کمپین، از تست بار سایت فقط یک اجرای کوتاه با همان اسکریپت و آستانه‌ها باقی می‌ماند. روز کمپین k6 را خاموش نگه دارید، شاخص‌های سرور را با عدد آزمون مقایسه کنید و نزدیک سقف، ارسال باقی پیامک‌ها را عقب بیندازید.

بعد از کمپین، لاگ‌ها را کنار خروجی k6 بایگانی کنید. اگر سقف یک سرور بعد از بهینه‌سازی هم کم بود، مطلب لود بالانسر چیست برای تقسیم بار در فصل بعد شروع خوبی است.

کمتر از یک هفته فرصت دارید و هنوز اسکریپتی ننوشته‌اید؟ شمارش معکوس شما از D-7 شروع می‌شود.

جمع‌بندی؛ برنامه‌ای که با یک تصمیم بسته می‌شود
تست بار سایت وقتی ارزش دارد که پیش از تبلیغ، با مجوز و با خبر میزبان انجام شود. چهارده روز مانده، عدد هدف و عدد پایه سرور را بردارید. هفت روز مانده، k6 را روی ماشینی جدا نصب کنید و قرارداد آستانه‌ها را پیش از اسکریپت بنویسید. سه روز مانده، با مدل باز پله‌پله بالا بروید؛ dropped_iterations از اعتبار اجرا خبر می‌دهد و http_req_waiting از جای گلوگاه. شب قبل همان اسکریپت را دوباره اجرا کنید و صبح کمپین، کارت برو یا نرو تصمیم را روشن می‌کند. فردای کمپین، لاگ‌ها و خروجی k6 را برای برنامه بعدی بایگانی کنید.

کمپین بعدی شما چه تاریخی است و تا امروز سایت را با حداکثر چند کاربر همزمان آزموده‌اید؟ تاریخ و عدد را همین پایین بگذارید.

منابع

• مستندات Grafana k6: نصب k6
• مستندات Grafana k6: آستانه‌ها
• مستندات Grafana k6: مدل باز و بسته
• مستندات Grafana k6: آزمون بار وب‌سایت‌ها
• مستندات Grafana k6: انواع آزمون