هاست ووکامرس به چه منابعی نیاز دارد؟
ووکامرس بهدلیل Checkout، سبد خرید، حساب کاربری، سفارش، موجودی، Webhook و کارهای پسزمینه با یک سایت محتوایی ساده متفاوت است. پلن مناسب باید منابع پویا، دیتابیس، کش، Cron و بکاپ را بر اساس رفتار واقعی فروشگاه تأمین کند؛ نه فقط تعداد محصول یا فضای دیسک.
پاسخ کوتاه: ووکامرس چه منابعی میخواهد؟
برای شروع ارزیابی، هاست ووکامرس باید PHP و دیتابیس بهروز، HTTPS، WordPress Memory Limit حداقل ۲۵۶ مگابایت، CPU و RAM حساب با حاشیه رشد، I/O پایدار، Cron سالم، Object Cache، بکاپ قابل بازیابی و مسیر ارتقای روشن داشته باشد. عدد دقیق CPU یا RAM برای همه فروشگاهها یکسان نیست.
تعداد محصول معیار کافی نیست. همزمانی کاربران، Variation، فیلتر، افزونهها، سفارش، API، Cron و Cache MISS بار واقعی را میسازند.
یک فروشگاه با ۲۰۰ محصول و فیلترهای سنگین ممکن است از فروشگاهی با ۲۰ هزار محصول و صفحات Cacheشده منابع بیشتری مصرف کند.
چرا ووکامرس از سایت شرکتی سنگینتر است؟
صفحه عمومی یک سایت شرکتی معمولاً میتواند از Full-page Cache پاسخ بگیرد. در ووکامرس بخشهایی مانند Cart، Checkout و My Account برای هر کاربر متفاوتاند و باید پویا بمانند. در این مسیر PHP، دیتابیس، Session، مالیات، حملونقل و درگاه پرداخت همزمان درگیر میشوند.
- ثبت و بهروزرسانی سفارش
- رزرو و کاهش موجودی
- محاسبه تخفیف، مالیات و حملونقل
- ارسال ایمیل و Webhook
- پردازش Scheduled Action و Subscription
- جستوجو، فیلتر و Variation محصول
حداقلهای رسمی با منابع واقعی چه تفاوتی دارند؟
مستندات WooCommerce محیط سازگار و WordPress Memory Limit حداقل ۲۵۶ مگابایت را توصیه میکند. این عدد سقف حافظه یک اجرای WordPress/PHP است و با RAM کل حساب هاست برابر نیست. چند Process همزمان، دیتابیس، Redis و سرویسهای دیگر به حافظه جدا نیاز دارند.
حداقل نرمافزاری فقط نصب و اجرای پایه را پوشش میدهد. ظرفیت فروشگاه باید با Load Test، Usage منابع و خطاهای واقعی سنجیده شود.
CPU در ووکامرس چه کارهایی را پردازش میکند؟
CPU اجرای PHP، محاسبه Hookها، Queryها، تولید HTML، پردازش تصویر، Import، Export و کارهای پسزمینه را انجام میدهد. Checkout و مدیریت سفارش معمولاً از صفحات Cacheشده حساسترند.
نشانههای کمبود CPU:
- TTFB بالای صفحات پویا
- کندی مدیریت و صفحه سفارشها
- Timeout در Import یا ساخت گزارش
- Fault منابع هنگام کمپین
- صف طولانی Scheduled Action
قبل از ارتقا، Query کند، افزونه پرهزینه و API خارجی را جدا کنید؛ CPU بیشتر خطای معماری را درمان نمیکند.
RAM و PHP Memory Limit
RAM حساب برای Processهای PHP، کش، عملیات فایل و بخشی از بار سرویسها مصرف میشود. PHP memory_limit یا WP_MEMORY_LIMIT سقف یک Process یا اجرای WordPress را کنترل میکند. اگر یک عملیات ۲۵۶ مگابایت مجاز باشد و چند Process همزمان اجرا شوند، مصرف کل میتواند چند برابر شود.
برای فروشگاه، حاشیه حافظه هنگام Import محصول، ساخت Thumbnail، گزارش، Backup و Update مهم است. خطای “Allowed memory size exhausted” نشانه مستقیم کمبود Memory Limit یا کد پرمصرف است؛ اما Kill شدن Process ممکن است از سقف RAM حساب بیاید.
I/O و IOPS
I/O سرعت انتقال داده از دیسک و IOPS تعداد عملیات ورودی/خروجی در ثانیه را نشان میدهد. ووکامرس با تعداد زیاد فایل کوچک، Log، Session، Cache، Upload و Query دیتابیس میتواند به هر دو حساس باشد.
- SSD یا NVMe بدون سقف I/O مناسب تضمین سرعت نیست.
- Backup و Malware Scan ممکن است موقتاً فشار دیسک ایجاد کنند.
- Import بزرگ و تولید تصویر به I/O و CPU همزمان نیاز دارند.
- دیتابیس شلوغ با Query بد از دیسک سریع هم بهره کامل نمیبرد.
Entry Process، NPROC و PHP Worker
Entry Process تعداد درخواستهای همزمان واردشده به محیط حساب را محدود میکند و NPROC تعداد Processهای فعال را میسنجد. مدل PHP Worker نیز تعیین میکند چند درخواست پویا همزمان پردازش شود. این شاخصها با «تعداد بازدیدکننده» یکی نیستند.
هنگام Checkout یا کمپین، درخواستهای AJAX، REST API و صفحات پویا میتوانند همزمانی را بالا ببرند. Fault مکرر EP یا صف Worker باعث تأخیر و خطای 508/503 میشود. راهنمای منابع هاست تفاوت این محدودیتها را کامل توضیح میدهد.
دیتابیس و HPOS
سفارش، محصول، مشتری، Coupon، Session و تنظیمات در دیتابیس نگهداری میشوند. WooCommerce در HPOS داده سفارش را در جدولهای اختصاصی و بهینهشده برای Queryهای تجارت الکترونیک ذخیره میکند. فعالبودن HPOS بهتنهایی همه مشکلات را حل نمیکند؛ سازگاری افزونهها، Index، Query و حجم داده همچنان مهماند.
- جدولهای Action Scheduler و Session را پایش کنید.
- Transient و Log منقضی را کنترل کنید.
- Queryهای بدون Index و گزارشهای سنگین را شناسایی کنید.
- قبل از تغییر HPOS از سازگاری افزونهها مطمئن شوید.
Page Cache و صفحات استثنا
Page Cache میتواند صفحات دسته، محصول و محتوای عمومی را سریع پاسخ دهد؛ اما Cart، Checkout و My Account باید پویا بمانند. مستندات رسمی WooCommerce توصیه میکند این مسیرها از Full-page Cache مستثنا شوند.
Cache HIT Ratio، علت MISS/BYPASS و زمان پاسخ صفحات پویا را جدا گزارش کنید. فروشگاه با HIT بالا در صفحات عمومی ممکن است منابع متوسطی بخواهد، اما همان فروشگاه در Checkout به Worker و دیتابیس قوی نیاز دارد.
Redis و Object Cache
Redis نتیجه Query و Objectهای تکراری WordPress را بین درخواستها نگه میدارد و میتواند فشار دیتابیس را کاهش دهد. Redis جای Page Cache نیست و باید برای هر حساب ایزوله، دارای Prefix/Database مناسب و محدودیت حافظه باشد.
پس از فعالسازی، Hit Ratio، Eviction، Memory Usage و رفتار Purge را بررسی کنید. Object Cache ناسازگار یا پرشده میتواند داده قدیمی یا فشار حافظه ایجاد کند. مقاله LiteSpeed و Redis معماری درست را توضیح میدهد.
Action Scheduler و Cron
WooCommerce برای Webhook، ایمیل، Subscription، Sync و بسیاری از کارهای پسزمینه از Action Scheduler استفاده میکند. وضعیت Scheduled Actions در WooCommerce Status قابل مشاهده است. صف Pending قدیمی یا Failed تکراری نشانه مشکل Cron، Loopback، حافظه یا کد افزونه است.
- Cron واقعی سرور را جایگزین اجرای وابسته به بازدید کنید.
- Jobهای سنگین را در ساعات کمترافیک زمانبندی کنید.
- همپوشانی Import، Backup و اسکن را کاهش دهید.
- Failed Action و Log را هشداردهی کنید.
تعداد محصول، Variation و جستوجو
تعداد محصول تنها بخشی از مسئله است. Variation زیاد، Attributeهای متعدد، فیلتر ترکیبی و Search زنده Query و حافظه را افزایش میدهد. صفحهای که ۵۰ محصول با چندین Variation و قیمت پویا بارگذاری میکند با صفحه ساده قابل مقایسه نیست.
برای کاتالوگ بزرگ، Pagination، Index مناسب، Search تخصصی، Lazy Load و محدودکردن Queryهای Meta را بررسی کنید.
درگاه پرداخت، API و سرویس خارجی
Checkout ممکن است منتظر درگاه، مالیات، حملونقل، پیامک، CRM یا ERP بماند. افزایش CPU سرور تأخیر API خارجی را حذف نمیکند. Timeout، Retry، Idempotency و Webhook Queue باید طراحی شوند تا سفارش دوباره ثبت یا گم نشود.
زمان هر Integration را جدا در Log ثبت کنید و برای قطعی سرویس خارجی مسیر Fail-safe داشته باشید.
بکاپ فروشگاه باید با سفارش هماهنگ باشد
بکاپ روزانه برای فروشگاهی که هر ساعت سفارش دارد ممکن است RPO مناسبی نباشد. دیتابیس سفارش و موجودی باید با فاصلهای ذخیره شود که از دستدادن آن برای کسبوکار قابل قبول باشد. فایلها معمولاً کمتر از دیتابیس تغییر میکنند و میتوانند برنامه متفاوتی داشته باشند.
- نسخه ساعتی یا کوتاهتر برای دیتابیس فروشگاه فعال
- بکاپ کامل روزانه یا دورهای
- نسخه خارج از سرور اصلی
- تست Restore روی محیط جدا
- برنامه بازگشت قبل از Update و Deploy
امنیت و ایزولهسازی
فروشگاه اطلاعات مشتری و سفارش را نگهداری میکند و هدف جذابی برای حمله است. جداسازی حسابها، WAF، اسکن بدافزار، Update سریع، 2FA، محدودیت ورود، Permission درست و Secret Management ضروریاند.
در هاست اشتراکی بپرسید Process، فایل، Redis و Temp هر حساب چگونه ایزوله میشود و در آلودگی یک سایت چه مانعی از دسترسی به حساب دیگر جلوگیری میکند.
جدول ارزیابی بر اساس نوع فروشگاه
| سناریو | فشار اصلی | اولویت منابع | آزمون ضروری |
|---|---|---|---|
| فروشگاه کوچک Cacheپذیر | صفحات عمومی و چند سفارش | منابع متوازن، کش و بکاپ | Product و Checkout |
| Variation و فیلتر زیاد | Query دیتابیس | CPU، RAM، Redis و Index | Filter و Search همزمان |
| کمپین پرترافیک | همزمانی و Cache MISS | Worker، EP و حاشیه CPU | Load Test با Checkout |
| Subscription | Scheduled Action و درگاه | Cron، Queue و مانیتورینگ | Renewal و Retry |
| اتصال ERP/Marketplace | API، Sync و Import | CPU، I/O و Job Control | Sync کامل و بازیابی خطا |
چطور بدون عددسازی پلن را انتخاب کنیم؟
- در یک هفته عادی و یک پیک، بازدید همزمان و سفارش را ثبت کنید.
- مصرف CPU، RAM، I/O، EP و Fault را از پنل بگیرید.
- Cache HIT و TTFB صفحات Product، Cart و Checkout را جدا بسنجید.
- Scheduled Action، Cron و Query کند را بررسی کنید.
- دو پلن را روی Staging یا دوره ضمانت با سناریوی یکسان تست کنید.
- پلنی انتخاب کنید که در اوج عادی نزدیک سقف نباشد و ارتقای ساده داشته باشد.
۱۸ سؤال از شرکت هاستینگ
- CPU و RAM واقعی حساب چقدر است؟
- I/O و IOPS چقدر است؟
- EP، NPROC و مدل PHP Worker چیست؟
- نسخه PHP و MariaDB کدام است؟
- WordPress Memory Limit تا چه حد قابل تنظیم است؟
- LiteSpeed و LSCache سروری ارائه میشود؟
- Redis چگونه ایزوله میشود؟
- HPOS و WooCommerce جدید پشتیبانی میشود؟
- Cron واقعی و WP-CLI وجود دارد؟
- Usage و Fault تاریخی قابل مشاهده است؟
- Backup دیتابیس چندبار است؟
- Restore انتخابی چقدر زمان میبرد؟
- Staging یا Clone ارائه میشود؟
- محدودیت ایمیل تراکنشی چیست؟
- WAF و Malware Scanner چگونهاند؟
- در پیک امکان ارتقای فوری وجود دارد؟
- پشتیبانی Checkout و Cron را تحلیل میکند؟
- قیمت تمدید و خدمات جانبی چیست؟
اشتباههای رایج
- خرید بر اساس تعداد محصول: رفتار Query و همزمانی مهمتر است.
- فرض Cacheشدن Checkout: صفحات شخصی باید پویا بمانند.
- یکساندانستن RAM و memory_limit: این دو شاخص متفاوتاند.
- نادیدهگرفتن Cron: صف Action Scheduler میتواند عملیات فروشگاه را مختل کند.
- تمرکز روی دیسک: فضای زیاد کمبود CPU و Worker را حل نمیکند.
- بکاپ روزانه برای فروشگاه فعال: ممکن است سفارشهای چند ساعت از دست برود.
جمعبندی: منابع را با مسیر خرید بسنجید
هاست ووکامرس مناسب باید صفحات عمومی Cacheشده و مسیرهای پویا را جدا مدیریت کند. CPU، RAM، I/O، PHP Worker، دیتابیس، Redis، Cron و Backup باید با هم دیده شوند. هیچ عدد واحدی برای همه فروشگاهها معتبر نیست؛ داده واقعی و تست سناریوی خرید مبنای تصمیم است.
برای مقایسه اولیه، مشخصات پلنهای هاست وردپرس FluxCDN را کنار چکلیست این مقاله و راهنمای انتخاب هاست وردپرس بر اساس بازدید قرار دهید.