تست بار سایت فروشگاهی قبل از بلک فرایدی و یلدا
تست بار سایت فروشگاهی قبل از بلک فرایدی و یلدا: چطور سایتتون روز حراج از دسترس خارج نشه
ساعت ده صبح روز حراج، پیامک تخفیف برای پنجاه هزار مشتری ارسال می‌شه. ساعت ده و سه دقیقه، صفحه‌ی اصلی سایت خطای ۵۰۲ می‌ده. تیم پشتیبانی زیر بار تماس‌ها غرق می‌شه، بودجه‌ی تبلیغات داره خرج می‌شه، و مشتری‌هایی که با اشتیاق اومده بودن، راهشون رو به سمت فروشگاه رقیب کج می‌کنن.
📘 اگر با مفاهیم پایه آشنا نیستید، پیشنهاد می‌کنیم اول مقاله‌ی تست نرم افزار چیست را بخوانید. تستتو خدمات برون سپاری تست نرم افزار را با قرارداد رسمی و NDA ارائه می‌دهد.
این سناریو برای خیلی از فروشگاه‌های اینترنتی ایرانی اتفاق افتاده. تقریباً همیشه هم یک دلیل مشترک داره: سایت هیچ‌وقت زیر بار واقعی تست نشده بود. توی این مقاله توضیح می‌دیم چرا سایت‌ها روز حراج می‌خوابن، تست بار دقیقاً چیه، و از امروز تا بلک‌فرایدی و شب یلدا چه کارهایی باید انجام بدید.
قبل از هر چیز، ببینید چند دقیقه قطعی در روز حراج چقدر براتون خرج داره:
🧮 قطعی سایت در روز حراج چقدر براتون خرج داره؟
چرا سایت‌های فروشگاهی روز حراج از دسترس خارج می‌شن؟
بیشتر مدیران فروشگاه فکر می‌کنن مشکل فقط «ضعیف بودن سرور» است و با ارتقای هاست حل می‌شه. در عمل، سرور معمولاً آخرین حلقه‌ی ضعیف زنجیره است. این‌ها رایج‌ترین مقصرها هستن:
دیتابیس و کوئری‌های سنگین
در روزهای عادی، یک کوئری کند که نیم ثانیه طول می‌کشه به چشم نمیاد. وقتی هزار نفر همزمان صفحه‌ی محصولات تخفیف‌دار رو باز می‌کنن، همون کوئری صف می‌کشه، اتصال‌های دیتابیس پر می‌شن، و کل سایت منتظر می‌مونه. فیلترها و جست‌وجوی محصولات معمولاً اولین نقطه‌ی شکستن.
سبد خرید، موجودی و قفل شدن رکوردها
وقتی صدها نفر همزمان یک محصول محدود رو به سبد اضافه می‌کنن، دیتابیس باید موجودی رو دقیق نگه داره. اگه این بخش درست طراحی نشده باشه، یا رکوردها قفل می‌شن و همه‌چیز کند می‌شه، یا بدتر از اون، یک کالا به دو نفر فروخته می‌شه.
سرویس‌های بیرونی: درگاه پرداخت، پیامک و API ارسال
سایت شما ممکنه آماده باشه، ولی پنل پیامکی که کد ورود یکبارمصرف (OTP) می‌فرسته محدودیت نرخ داره. درگاه پرداخت هم زیر بار کند جواب می‌ده. وقتی کاربر نتونه وارد بشه یا پرداختش معلق بمونه، برای اون فرقی نداره که مقصر کیه؛ از نگاه اون «سایت خراب بود».
کش اشتباه یا کش نکردن
صفحاتی که می‌تونستن یک بار ساخته بشن و به همه نمایش داده بشن، برای هر بازدیدکننده از اول ساخته می‌شن. از اون طرف، گاهی صفحات سبد خرید یا پرداخت اشتباهی کش می‌شن و کاربر سبد خرید نفر دیگه رو می‌بینه.
💡 نکته برای فروشگاه‌های ووکامرسی
در بسیاری از سایت‌های ووکامرسی، درخواست‌های پس‌زمینه‌ای مثل به‌روزرسانی مینی‌سبد خرید (wc-ajax=get_refreshed_fragments)، فراخوانی‌های admin-ajax.php و اجرای wp-cron روی هر بازدید، بدون اینکه دیده بشن بخش بزرگی از منابع سرور رو مصرف می‌کنن. قبل از خرید سرور قوی‌تر، این‌ها رو بررسی کنید و از یک آبجکت کش مثل Redis استفاده کنید.
تست بار، تست استرس و تست اسپایک چه فرقی دارن؟
«تست بار» اسم عمومی چند نوع تست متفاوته که هر کدوم به یک سؤال جواب می‌دن. برای یک فروشگاه اینترنتی، هر سه لازمه:
تست بار (Load Test)
رفتار سایت در ترافیکی که انتظارش رو دارید، مثلاً سه برابر یک روز عادی و به مدت چند ساعت.
جواب می‌ده: «با ترافیک پیش‌بینی‌شده، سایت سریع می‌مونه؟»
تست استرس (Stress Test)
ترافیک رو قدم‌به‌قدم بالا می‌بریم تا سایت بشکنه، و می‌بینیم کجا و چطور می‌شکنه.
جواب می‌ده: «سقف واقعی ظرفیت ما چند کاربر همزمانه؟»
تست اسپایک (Spike Test)
شبیه‌سازی هجوم ناگهانی، مثل چند ثانیه بعد از ارسال پیامک تخفیف یا شروع شمارش معکوس حراج.
جواب می‌ده: «اگه همه یک‌دفعه بیان، سایت دووم میاره؟»
نکته‌ی مهمی که خیلی‌ها ازش غافلن اینه که تست بار باید سناریوی واقعی خرید رو شبیه‌سازی کنه، نه فقط باز کردن صفحه‌ی اصلی. کاربر واقعی وارد می‌شه، جست‌وجو می‌کنه، فیلتر می‌زنه، محصول رو به سبد اضافه می‌کنه و پرداخت می‌کنه. اگه فقط صفحه‌ی اصلی رو زیر بار ببرید، جوابی می‌گیرید که بیشتر از اینکه کمک کنه گمراه‌کننده‌ست.
در خدمات تست پرفورمنس تستتو، گزارش نهایی فقط نمودار نیست. دقیقاً مشخص می‌کنیم کدوم کوئری، کدوم تنظیم سرور یا کدوم بخش کد گلوگاه شده.
چک‌لیست ۱۰ مرحله‌ای آمادگی سایت برای حراج
این چک‌لیست رو با تیم فنی‌تون مرور کنید. هر موردی که تیک نمی‌خوره، یک ریسک واقعی برای روز حراجه:
✅ چک‌لیست آمادگی حراج
تقویم عقب‌رو: از امروز تا بلک‌فرایدی و یلدا
بلک‌فرایدی جهانی امسال جمعه ۶ آذر (۲۷ نوامبر) است و شب یلدا ۳۰ آذر. بیشتر فروشگاه‌های ایرانی کمپین‌هاشون رو حوالی همین تاریخ‌ها اجرا می‌کنن. تست بار یک کار یک‌روزه نیست؛ هر بار که گلوگاهی پیدا می‌شه، باید رفع بشه و دوباره تست بشه. به همین خاطر زمان‌بندی از همه چیز مهم‌تره:
🗓 برنامه‌ی آمادگی تا روز حراج
- تا ۲۰ مهر: برآورد و طراحی سناریوترافیک هدف رو عدد کنید و مسیرهای حیاتی خرید رو برای تست بنویسید.
- ۲۰ مهر تا ۵ آبان: تست پایهاولین تست بار، برای اینکه بدونید امروز کجا ایستادید و اولین گلوگاه‌ها کدومن.
- آبان: رفع گلوگاه‌ها و تست استرسبهینه‌سازی کوئری‌ها، کش و زیرساخت، تست دوباره، و پیدا کردن نقطه‌ی شکست واقعی.
- ۲۵ آبان تا ۱ آذر: تست اسپایک نهایی و فریز کدآخرین تست با سناریوی لحظه‌ی ارسال پیامک. از این به بعد، تغییری در کد داده نمی‌شه.
- ۶ آذر: روز حراجمانیتورینگ زنده، تیم آنکال، و پلن B آماده.
- ۷ تا ۳۰ آذر: درس‌ها برای یلداداده‌های واقعی بلک‌فرایدی رو تحلیل کنید و قبل از یلدا نقاط ضعف باقی‌مانده رو ببندید.
اگه این مقاله رو دیرتر از این تاریخ‌ها می‌خونید، ناامید نشید. حتی یک تست اسپایک ساده چند روز قبل از حراج هم می‌تونه بزرگ‌ترین ریسک رو نشونتون بده. فقط زمان کمتری برای رفع مشکلات خواهید داشت.
یک نمونه‌ی واقعی: گلوگاهی که کسی انتظارش رو نداشت
📊 کیس‌استادی: فروشگاه [حوزه‌ی فعالیت، مثلاً پوشاک]
این فروشگاه برای کمپین [نام کمپین] انتظار حدود [عدد] کاربر همزمان رو داشت. در تست بار مشخص شد که [گلوگاه اصلی، مثلاً کوئری فیلتر محصولات] در [عدد] کاربر همزمان باعث قفل شدن دیتابیس می‌شه.
نکته‌ی این نمونه‌ها معمولاً یکیه: مشکل جایی نبود که تیم فنی حدس می‌زد. به همین دلیله که تست بار جای «حدس و ارتقای سرور» رو می‌گیره.
خودتون چه کاری می‌تونید بکنید و کجا به متخصص نیاز دارید؟
بخشی از آمادگی رو تیم خودتون هم می‌تونه انجام بده: فعال کردن کش و CDN، بهینه‌سازی تصاویر، حذف افزونه‌های اضافه، و گرفتن اطلاعات ظرفیت از پنل پیامک و درگاه پرداخت. ابزارهای متن‌باز مثل k6 و JMeter هم برای شروع تست بار در دسترس هستن.
ولی یک تست بار قابل اعتماد به سه چیز نیاز داره که معمولاً تیم‌های فروشگاهی ندارن:
- سناریوی واقعی. یعنی شبیه‌سازی رفتار کاربر با ورود، سبد خرید و پرداخت، نه فقط باز کردن صفحه.
- زیرساخت تولید بار. برای ساختن هزاران کاربر مجازی، سرورهای جداگانه لازمه. تست از روی لپ‌تاپ خود تیم معمولاً سقف لپ‌تاپ رو اندازه می‌گیره، نه سقف سایت رو.
- تحلیل ریشه‌ای. اینکه بدونید بعد از دیدن عدد بد، دقیقاً کدوم بخش رو باید درست کرد.
جمع‌بندی
روز حراج، روزیه که بیشترین پول رو برای آوردن مشتری به سایت خرج کردید. اگه سایت اون روز از دسترس خارج بشه، هم فروش از دست رفته، هم بودجه‌ی تبلیغات هدر رفته، و هم مشتری‌ای که شاید دیگه برنگرده. تست بار هزینه‌ی کوچیکیه در برابر این ریسک، به شرطی که به موقع انجام بشه.
☕ همین الان وضعیت سایتتون رو بسنجید
با کافه تستتو در چند ثانیه یک آنالیز رایگان از پرفورمنس، امنیت و سئوی سایتتون بگیرید. برای آمادگی کامل حراج، تیم تستتو تست بار، استرس و اسپایک رو با سناریوی واقعی خرید انجام می‌ده.
آنالیز رایگان در کافه تستتو رزرو تست بار قبل از حراجآیا تست بار روی سایت اصلی انجام می‌شه؟
بهترین حالت، محیطی مشابه سایت اصلی (Staging) است. اگه لازم باشه روی سایت اصلی انجام بشه، باید در ساعت کم‌ترافیک و با هماهنگی شرکت هاستینگ باشه، چون ترافیک سنگین تست ممکنه به‌عنوان حمله شناسایی و مسدود بشه.
تست بار چقدر زمان می‌بره؟
خود اجرای تست چند ساعت طول می‌کشه. کل چرخه، یعنی طراحی سناریو، تست، رفع گلوگاه‌ها و تست دوباره، معمولاً چند هفته زمان می‌بره. به همین خاطر بهتره حداقل یک ماه قبل از حراج شروع کنید.
سایت ووکامرسی کوچیک هم به تست بار نیاز داره؟
اگه برای حراج تبلیغ یا پیامک انبوه ارسال می‌کنید، بله. سایت‌های کوچیک معمولاً روی هاست‌های اشتراکی با منابع محدود هستن و زودتر از سایت‌های بزرگ از دسترس خارج می‌شن.
ارتقای سرور کافی نیست؟
گاهی کمک می‌کنه، ولی اگه گلوگاه در دیتابیس، کد یا یک سرویس بیرونی مثل پنل پیامک باشه، سرور قوی‌تر مشکل رو حل نمی‌کنه و فقط هزینه رو بالا می‌بره. تست بار نشون می‌ده پول رو دقیقاً کجا خرج کنید.
با چند کاربر همزمان باید تست کنیم؟
حداقل با اوج ترافیک پیش‌بینی‌شده، و ترجیحاً دو تا سه برابرش، چون کمپین‌های موفق معمولاً از پیش‌بینی جلو می‌زنن. تست استرس هم سقف واقعی رو مشخص می‌کنه.