وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

چطور ظرفیت سایت را بدون آسیب به فروشگاه آزمایش کنیم؟

برنامه مرحله‌به‌مرحله تست ظرفیت فروشگاه با حفظ سفارش، پرداخت و اطلاعات مشتری.

انتشار:
توسط تیم فنی نت‌آرام
۷ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله چطور ظرفیت سایت را بدون آسیب به فروشگاه آزمایش کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
پیش از کمپین می‌خواهید بدانید فروشگاه در شلوغی چه رفتاری دارد. فرستادن تعداد زیادی درخواست به سایت فعال بدون هماهنگی می‌تواند خرید واقعی را مختل کند. آزمون مفید از یک سناریوی مشخص و محیط امن شروع می‌شود، نه از فشار ناگهانی.

اول سؤال آزمون را مشخص کنید

مثلاً می‌خواهید بدانید اگر تعداد مشخصی مشتری هم‌زمان صفحه محصول را باز کنند و بخشی از آن‌ها به سبد بروند، زمان پاسخ و خطا چقدر می‌شود. تعداد کاربران، فاصله فعالیت‌ها و نوع صفحه باید با رفتار مورد انتظار کسب‌وکار هماهنگ باشد. بازکردن پشت سر هم صفحه اصلی، تمام مراحل خرید را شبیه‌سازی نمی‌کند.

محیط آزمایشی و محدودیت‌ها را آماده کنید

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

فشار را تدریجی بالا ببرید

ابتدا با یک کاربر مجازی مسیر را امتحان کنید. سپس بار را پله‌ای و با فاصله زمانی افزایش دهید و در هر مرحله تعداد درخواست‌ها، خطاها و زمان پاسخ را ثبت کنید. ابزار آزمون باید قابل تنظیم باشد و گزارش آن مشخص کند هر کاربر مجازی چه کاری انجام داده است.
قبل از اجرا با مدیر سایت و میزبان زمان و حد توقف را مشخص کنید: مثلاً افزایش محسوس خطا یا کندی شدید. مسئول آزمون باید بتواند فوراً اجرای آن را متوقف کند. بدون اجازه و هماهنگی، سایت یا سرویس دیگران را تحت فشار قرار ندهید.
برای یک شروع فرضی در محیط آزمایشی، اول یک کاربر مجازی را یک دقیقه روی مسیر مشخص اجرا کنید. اگر نتیجه درست است، با توافق میزبان پنج کاربر و سپس ده کاربر را در بازه‌های جدا امتحان کنید و بین مرحله‌ها اجازه دهید وضعیت پایدار شود. این عددها ظرفیت پیشنهادی برای همه سایت‌ها نیستند. برای هر مرحله تعداد خطا و زمانی را که ۹۵ درصد درخواست‌ها در آن کامل شده‌اند ثبت کنید؛ مثلاً اگر این عدد از یک ثانیه به هشت ثانیه برسد، بخشی از کاربران به‌طور محسوس بیشتر منتظر می‌مانند. اگر از آستانه توقف توافق‌شده عبور کردید، آزمون را متوقف کنید و علت را پیش از مرحله بعد پیدا کنید. راهنمای شاخص‌های k6 درباره این عددها توضیح می‌دهد.

یک نمونه واقعی برای صفحه محصول آزمایشی

این نمونه فقط یک صفحه محصول عمومی در محیط آزمایشی را می‌خواند؛ پرداخت نمی‌کند و سبد خرید نمی‌سازد. نخست با میزبان و مدیر سایت هماهنگ کنید، یک محصول آزمایشی بدون اطلاعات مشتری بسازید و مطمئن شوید نشانی آن زیر دامنه‌ای مانند staging.example.com است. خود example.com نمونه است؛ هیچ آزمایشی روی سایتی که اجازه ندارید انجام ندهید.
ابزار رایگان k6 را روی رایانه آزمایش نصب کنید. راه نصب ویندوز، لینوکس و مک در مستندات رسمی k6 آمده است. مثلاً در ویندوز، اگر Windows Package Manager را دارید، PowerShell را باز کنید و بنویسید:
کد / دستورwinget install k6 --source winget
پس از پایان نصب، یک پنجره تازه PowerShell باز کنید و با دستور زیر مطمئن شوید برنامه در دسترس است:
کد / دستورk6 version
حالا در یک پوشه کاری، فایلی به نام capacity-test.js بسازید و متن زیر را داخل آن ذخیره کنید. این برنامه آدرس را از تنظیمات محیط می‌خواند، فقط نام‌هایی را می‌پذیرد که با staging. شروع می‌شوند و تغییر مسیر خودکار را دنبال نمی‌کند؛ با این حال، مالک و مجازبودن نشانی را خودتان باید تأیید کنید.
کد / دستورimport http from 'k6/http'; import { check, sleep } from 'k6'; const target = __ENV.STAGING_URL || ''; const permitted = /^https:\/\/staging\.[a-z0-9.-]+(?:\/[^\s?#]*)?$/i; if (!permitted.test(target) || target.includes('example.com')) { throw new Error('نشانی HTTPS محیط staging مجاز را در STAGING_URL بگذارید.'); } export const options = { thresholds: { http_req_failed: [{ threshold: 'rate<0.01', abortOnFail: true, delayAbortEval: '15s' }], checks: [{ threshold: 'rate>0.99', abortOnFail: true, delayAbortEval: '15s' }], }, }; export default function () { const response = http.get(target, { redirects: 0, timeout: '10s' }); check(response, { 'صفحه پاسخ 200 داد': (r) => r.status === 200 }); sleep(2); }
در PowerShell زیر، نشانی نمونه را با نشانی کامل محیط آزمایشی خودتان جایگزین کنید و از همان پوشه فایل، آزمایش یک کاربر برای یک دقیقه را اجرا کنید:
کد / دستور$env:STAGING_URL = 'https://staging.example.com/product/demo/' k6 run --vus 1 --duration 1m capacity-test.js
برنامه عمداً example.com را قبول نمی‌کند؛ اگر خطای نشانی دیدید، هنوز مقدار نمونه را عوض نکرده‌اید یا نام میزبان با staging. شروع نمی‌شود. در صورت پاسخ ۳۰۱ یا ۳۰۲، آزمون را ادامه ندهید: نشانی محیط آزمایشی ممکن است به سایت اصلی هدایت شود. نشانی و تنظیم محیط را اصلاح کنید، نه اینکه دنبال‌کردن تغییر مسیر را بی‌فکر فعال کنید.
اگر نتیجه مرحله اول سالم بود، با هماهنگی میزبان همین دستور را با --vus 5 و سپس --vus 10 تکرار کنید. هر بار یک دقیقه جداگانه اجرا می‌شود. اگر سایت آزمایشی کند شد یا خطا بالا رفت، Ctrl+C بزنید؛ شرط‌های برنامه نیز پس از فرصت اولیه در صورت خطای زیاد آزمون را متوقف می‌کنند. به سایت‌های دیگری که داخل صفحه لینک شده‌اند درخواست فشار نمی‌فرستیم، چون این نمونه فقط همان نشانی را می‌خواند.
در خروجی، checks نشان می‌دهد چه تعداد پاسخ واقعاً کد ۲۰۰ داشته‌اند؛ http_req_failed نرخ خطا و http_req_duration زمان درخواست را نشان می‌دهد. برای مثال، p(95)=800ms یعنی ۹۵ درصد درخواست‌های ثبت‌شده حداکثر حدود ۸۰۰ میلی‌ثانیه طول کشیده‌اند. زمان اتصال اولیه شبکه در این شاخص جداست. این عدد و تعداد خطاها را برای هر مرحله کنار مصرف منابع ثبت کنید. یک پاسخ ۲۰۰ به‌تنهایی درستی همه محتوای صفحه را ثابت نمی‌کند؛ صفحه را با مرورگر هم ببینید.
اگر نصب برنامه یا مجوز اجرای آزمون بار ندارید، یک حساب آزمایشی بسازید، همان صفحه را در مرورگر باز کنید و در F12 → Network زمان درخواست صفحه را سه بار ثبت کنید. بعد از اصلاح، همان سه آزمایش را تکرار کنید. این روش برای مقایسه یک کاربر مفید است، اما ظرفیت چند کاربر هم‌زمان را مشخص نمی‌کند؛ برای آن باید آزمون هماهنگ با میزبان داشته باشید.

بعد از آزمون، نتیجه واقعی را بخوانید

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

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام