فروش ویژه ضعف‌هایی را آشکار می‌کند که در ترافیک عادی دیده نمی‌شوند: صفحه محصول از cache سریع است اما Checkout worker کم می‌آورد، رزرو موجودی با درخواست‌های هم‌زمان ناسازگار می‌شود، درگاه rate-limit می‌کند یا صف ایمیل و webhook ساعت‌ها عقب می‌افتد. آماده‌سازی باید کل مسیر خرید را پوشش دهد، نه فقط صفحه اصلی.
پاسخ سریع: مسیر واقعی از مشاهده محصول تا پرداخت و callback را با بار مرحله‌ای روی محیط مشابه production آزمایش کنید. ظرفیت PHP، دیتابیس، session، درگاه و صف را کنار هم بسنجید. پیش از شروع، freeze تغییرات، dashboard، alert، runbook و مسئول تصمیم‌گیری مشخص داشته باشید؛ افزایش ناگهانی worker در روز فروش برنامه ظرفیت نیست.
تقاضا را به سناریوی فنی تبدیل کنید
عدد بازدیدکننده به‌تنهایی برای ظرفیت‌سنجی کافی نیست. نرخ مشاهده محصول، جست‌وجو، افزودن به سبد، update Checkout و ثبت سفارش را تخمین بزنید. یک کاربر در چند دقیقه چند request می‌سازد و asset، Ajax و API خارجی رفتار متفاوت دارند. ربات و refresh مکرر را از خرید واقعی تفکیک کنید.
| مسیر | قابل Cache؟ | منبع بحرانی |
|---|---|---|
| Landing و دسته عمومی | اغلب بله | CDN، origin miss و asset |
| جست‌وجو/فیلتر | وابسته به query | دیتابیس و PHP |
| سبد و حساب | عمومی خیر | session و worker |
| Checkout | عمومی خیر | PHP، DB، ارسال و درگاه |
| Callback/Webhook | خیر | امنیت، idempotency و DB |
Baseline عادی را ثبت کنید
p50 و p95 زمان پاسخ، نرخ خطا، PHP queue، CPU، available RAM، I/O، Query time، connection و سن صف را در روز عادی ثبت کنید. بدون baseline نمی‌دانید کمپین کدام شاخص را تغییر داده است. deployment، import و backup را نیز روی timeline علامت بزنید.
Load Test ایمن و واقع‌گرایانه
آزمون را با پرداخت واقعی روی production اجرا نکنید. staging با نسخه، داده ناشناس‌شده و topology نزدیک بسازید. از نرخ کم شروع و مرحله‌ای افزایش دهید؛ read و write را جدا و سپس ترکیب کنید. داده آزمایش، ایمیل و webhook نباید به سیستم واقعی مشتری یا ERP ارسال شود.
فقط requests per second را گزارش نکنید. نرخ سفارش صحیح، duplicate، timeout، صف، فشار دیتابیس و زمان بازیابی بعد از بار مهم‌اند. اگر نتیجه با cache گرم گرفته شده، warm-up و نسبت hit را مستند کنید.
Cache صفحات عمومی و مسیر خرید
Landing، دسته و محصول عمومی می‌توانند از CDN/page cache سود ببرند، اما Cart، Checkout و My Account باید bypass درست داشته باشند. cache key باید زبان، ارز و شخصی‌سازی را لحاظ کند. نمایش موجودی یا قیمت قدیمی برای رسیدن به latency کمتر قابل قبول نیست.
Cache Stampede هنگام شروع کمپین
اگر هزاران کاربر هم‌زمان به صفحه منقضی‌شده برسند، همه ممکن است origin را برای بازسازی صدا بزنند. TTL، stale strategy و warm-up را طبق قابلیت cache طراحی کنید. purge کامل درست پیش از شروع، بدون warm-up، بیشترین فشار را در بدترین زمان ایجاد می‌کند.
Checkout ظرفیت Dynamic می‌خواهد
Checkout از cache کامل عبور می‌کند. active worker، queue، مدت request و حافظه هر process را اندازه بگیرید. افزایش worker فقط تا جایی مفید است که RAM و دیتابیس ظرفیت داشته باشند. راهنمای فروشگاه سریع و Checkout کند این تفاوت را مرحله‌ای بررسی می‌کند.
دیتابیس و رقابت عملیات
ثبت سفارش، کاهش موجودی، session و گزارش‌گیری هم‌زمان read/write دارند. Query کند، lock و I/O را در آزمون مشاهده کنید. backup، import محصول و گزارش سنگین را از پنجره فروش دور کنید، اما مانیتور و backup اضطراری را حذف نکنید. index حدسی در آستانه کمپین پرریسک است.
Connection Pool و سقف دیتابیس
worker بیشتر می‌تواند connection بیشتری به دیتابیس باز کند. اگر سقف connection یا ظرفیت Query پایین‌تر باشد، افزایش PHP concurrency فقط صف را از وب‌سرور به دیتابیس منتقل می‌کند. تعداد active/idle، زمان Query و lock را در load test ببینید و connection را بدون بودجه RAM افزایش ندهید.
موجودی هم‌زمان و Overselling
نمایش «موجود» با رزرو یا کاهش امن هنگام سفارش فرق دارد. دو درخواست هم‌زمان برای آخرین کالا را در staging تست کنید. cache موجودی، ERP sync و زمان release سفارش لغوشده باید روشن باشد. برای افزایش فروش validation موجودی را دور نزنید؛ نتیجه تعهد تحویل غیرواقعی است.
درگاه و محدودیت خارجی
نرخ مجاز، timeout، callback، webhook و inquiry را با ارائه‌دهنده بررسی کنید. timeout به معنی شکست قطعی نیست و retry باید idempotent باشد. درگاه جایگزین فقط وقتی مفید است که از قبل قرارداد، تنظیم، reconciliation و smoke test شده باشد؛ نصب عجولانه افزونه در incident ریسک مالی می‌سازد.
Action Scheduler و صف
ایمیل، webhook، sync و cleanup ممکن است در صف باشند. نرخ schedule و complete، سن قدیمی‌ترین pending و failed rate را baseline کنید. افزایش فروش producer را سریع‌تر می‌کند. مقاله Action Scheduler ووکامرس نشان می‌دهد چرا حذف یا Run All راه‌حل backlog نیست.
Session، Redis و چند Node
در چند node، session، cache namespace، clock و نسخه کد باید سازگار باشند. Redis فقط با hit rate، memory، eviction و failure test قابل اتکاست. restart آن در اوج ترافیک می‌تواند cache miss گسترده و فشار ناگهانی دیتابیس ایجاد کند.
ربات، Rate Limit و صف خرید
WAF و rate limit باید abuse را مهار کنند بدون اینکه callback درگاه یا مشتری واقعی block شود. rule را پیش از کمپین با traffic کنترل‌شده آزمایش و request ID نگه دارید. CAPTCHA یا queue page روی conversion و accessibility اثر دارد و باید از قبل یکپارچه شود.
Freeze و چک‌لیست ۲۴ ساعت آخر
- عدم deployment و تغییر plugin غیرضروری
- تأیید backup و مسیر restore
- آزمون خرید، لغو و callback کنترل‌شده
- بررسی certificate، DNS و زمان سیستم
- ظرفیت دیسک، log rotation و quota سرویس‌ها
- تأیید alert و دسترسی افراد on-call
- ثبت config و نسخه image فعال
Dashboard روز فروش
ترافیک، cache hit، p95 مسیرها، نرخ خطا، PHP queue، DB latency، سفارش در دقیقه، موفقیت پرداخت و backlog را کنار هم ببینید. metric تجاری و فنی را مرتبط کنید. داده پرداخت و مشتری را در dashboard عمومی نمایش ندهید.
Runbook رخداد
- شدت و مسیر متاثر را مشخص کنید.
- آخرین تغییر و timeline را ثبت کنید.
- جلوی تغییرات هم‌زمان را بگیرید.
- اقدام کم‌ریسک و آزموده‌شده اجرا کنید.
- بعد از هر اقدام metricها را دوباره بخوانید.
- سفارش و پرداخت مبهم را reconcile کنید.
- پس از پایداری postmortem ثبت کنید.
Rollback باید سفارش‌های تازه را حفظ کند
rollback image نباید دیتابیس را بدون توجه به migration عقب ببرد. restore کامل backup قدیمی سفارش‌های لحظات اخیر را حذف می‌کند. مسیر بازگشت هر release را پیش از کمپین روی clone تست و برنامه حفظ writeهای جدید را مستند کنید.
آزمون Failure، نه فقط موفقیت
کندی درگاه، قطع Redis، timeout webhook و پر شدن صف را کنترل‌شده روی staging شبیه‌سازی کنید. سیستم باید پیام روشن بدهد و retry تکراری نسازد. recovery و warm-up پس از برگشت سرویس را نیز اندازه بگیرید؛ بسیاری از incidentها در موج بازیابی رخ می‌دهند.
ظرفیت پشتیبانی مشتری
خطای فنی تنها فشار روز فروش نیست. پاسخ استاندارد برای پرداخت مبهم، SLA پیگیری و دسترسی امن به شناسه سفارش آماده کنید. از مشتری درخواست پرداخت مجدد نکنید تا وضعیت قبلی inquiry شود. تیم پشتیبانی نباید secret یا داده کارت دریافت کند.
برنامه پایان کمپین
بعد از افت ترافیک فوراً monitor یا ظرفیت موقت را خاموش نکنید. webhook، ایمیل، sync و گزارش ممکن است هنوز backlog داشته باشند. سفارش‌های Pending/Failed، پرداخت‌های موفق بدون تأیید، موجودی منفی و actionهای عقب‌افتاده را تا رسیدن به وضعیت نهایی بررسی کنید.
ظرفیت موقت را پس از مشاهده نرخ تخلیه و بازگشت metricها کاهش دهید. داده آزمون و ruleهای اضطراری را با change record پاک‌سازی کنید و یافته‌های postmortem را به test plan کمپین بعدی اضافه کنید.
اشتباه‌های رایج
- آزمون فقط صفحه اصلی cacheشده
- purge کامل درست پیش از شروع
- افزایش worker بدون RAM و DB
- خاموش کردن WAF یا TLS
- Load Test مالی روی production
- تغییر plugin در روز فروش
- نادیده گرفتن reconciliation
چه زمانی کمک تخصصی لازم است؟
اگر فروش ویژه درآمد را در بازه کوتاه متمرکز می‌کند، ظرفیت‌سنجی و runbook باید پیشاپیش آماده باشد. پشتیبانی فروشگاه ووکامرس می‌تواند مسیر خرید، دیتابیس، PHP، cache، درگاه و صف را با آزمون کنترل‌شده اعتبارسنجی کند.
پرسش‌های متداول
چند کاربر هم‌زمان را ووکامرس تحمل می‌کند؟
عدد ثابت ندارد؛ نسبت مسیر cacheشده/dynamic، مدت request، دیتابیس و سرویس خارجی ظرفیت را تعیین می‌کنند.
آیا CDN کافی است؟
صفحات عمومی را سبک می‌کند، اما Checkout، session، سفارش و درگاه در origin پردازش می‌شوند.
روز قبل سرور را ارتقا دهیم؟
تغییر آزمون‌نشده ریسک دارد. ظرفیت جدید باید با load test، مانیتور و rollback اعتبارسنجی شود.
پس از فروش چه کنیم؟
پرداخت مبهم، duplicate، موجودی، failed job، webhook و روند منابع را reconcile و postmortem کنید.