برای ووکامرس ترکیب ثابتی مثل «۴ هسته و ۸ گیگ RAM» پاسخ همگانی نیست. فروشگاهی با ده‌هزار محصول و page cache بالا ممکن است سبک‌تر از فروشگاه کوچک با قیمت‌گذاری پویا، فیلتر سنگین و صدها Checkout هم‌زمان باشد. انتخاب سرور باید از workload، سطح پشتیبانی و هدف بازیابی شروع شود، نه تعداد محصول یا تبلیغ پلن.
پاسخ کوتاه: نرخ درخواست dynamic، مدت PHP، Query و I/O، کاربران هم‌زمان، سفارش در دقیقه و سرویس‌های جانبی را اندازه بگیرید. سپس CPU، RAM، storage، شبکه و ظرفیت دیتابیس را با حاشیه امن انتخاب کنید. اگر تیم مدیریت سیستم ندارید، VPS خام حتی با منابع بیشتر می‌تواند از هاست مدیریت‌شده پرریسک‌تر باشد.
پرسش‌های قبل از خرید
- چند request از page cache عبور می‌کند؟
- پیک ترافیک و سفارش چه زمانی است؟
- Checkout چند API خارجی دارد؟
- کاتالوگ چند variation و فیلتر دارد؟
- import، backup و گزارش چه زمانی اجرا می‌شوند؟
- RPO و RTO چیست؟
- چه کسی patch و incident را مدیریت می‌کند؟
CPU؛ هسته بیشتر همیشه سریع‌تر نیست
PHP requestها در workerهای جدا اجرا می‌شوند و concurrency از هسته بیشتر سود می‌برد، اما سرعت تک‌هسته برای request طولانی مهم است. Query، compression و job پس‌زمینه با CPU رقابت می‌کنند. تعداد vCPU بدون دانستن نسل، سهم و noisy neighbor قابل مقایسه نیست.
RAM را بین سرویس‌ها بودجه‌بندی کنید
سیستم‌عامل، PHP-FPM، MySQL، Redis، وب‌سرور و مانیتورینگ حافظه می‌خواهند. worker بیشتر مصرف را بالا می‌برد. هدف فقط جلوگیری از OOM نیست؛ دیتابیس باید buffer مناسب داشته باشد و سیستم وارد swap سنگین نشود. available memory و p95 process را مبنا بگیرید.
Storage و IOPS
ثبت سفارش، session، log، import تصویر و backup به storage وابسته‌اند. برچسب SSD/NVMe کافی نیست؛ latency، IOPS پایدار، throughput، quota و snapshot مهم است. دیسک نزدیک پر، inode تمام‌شده یا backup هم‌زمان فروشگاه را کند می‌کند.
دیتابیس روی همان سرور یا جدا؟
برای workload کوچک، هم‌مکانی ساده‌تر است. با رشد، جداسازی رقابت منابع و failure domain را تغییر می‌دهد، اما latency شبکه، هزینه و پیچیدگی اضافه می‌کند. پیش از جداسازی Query و I/O را اندازه بگیرید؛ انتقال Query بد آن را اصلاح نمی‌کند.
PHP Worker و ظرفیت
هر Checkout dynamic یک worker واقعی می‌خواهد. اگر همه مشغول باشند، درخواست در صف می‌ماند حتی اگر محصول cacheشده سریع باشد. تعداد worker باید با مدت request، concurrency و RAM هر process هماهنگ شود. افزایش نامحدود دیتابیس را اشباع یا OOM ایجاد می‌کند.
MySQL و Query واقعی
CPU دیتابیس، buffer hit، connection، lock، temporary work و slow query را ببینید. حجم دیتابیس یا تعداد محصول به‌تنهایی اندازه سرور را تعیین نمی‌کند. N+1 و فیلتر بدون index هر سخت‌افزاری را هدر می‌دهد. plan و caller را پیش از scale-up اصلاح کنید.
Redis؛ بخشی از ظرفیت، نه الزام
Object cache در workload خواندنی تکراری ممکن است بار دیتابیس را کم کند، اما RAM، مانیتورینگ و failure behavior می‌خواهد. اگر API درگاه کند یا Query منحصربه‌فرد است، اثر محدود است. تصمیم را با hit/miss، eviction و baseline بگیرید.
هاست اشتراکی چه زمانی کافی است؟
برای فروشگاه کم‌ترافیک با افزونه محدود و پشتیبانی مناسب ممکن است کافی باشد. محدودیت process، worker، cron، دیتابیس، SSH و noisy neighbor را شفاف بخواهید. بررسی نقش هاست در کندی روش اثبات محدودیت را توضیح می‌دهد.
چه زمانی VPS منطقی است؟
نیاز به تنظیم PHP/DB، cron واقعی، سرویس جانبی، مانیتورینگ و isolation دلایل معتبرند. VPS مسئولیت patch، firewall، backup و on-call را نیز منتقل می‌کند. انتقال از هاست اشتراکی به VPS معیارها را کامل می‌کند.
Managed یا Unmanaged؟
| انتخاب | مزیت | هزینه پنهان |
|---|---|---|
| هاست مدیریت‌شده | عملیات ساده و پشتیبانی | کنترل محدود |
| VPS مدیریت‌شده | کنترل همراه مسئول عملیات | وابستگی به محدوده SLA |
| VPS خام | انعطاف کامل | امنیت و on-call با شما |
| چندسرویس | مقیاس و isolation | پیچیدگی و هزینه |
شبکه و موقعیت کاربران
latency کاربر تا origin، DNS و CDN اثر دارند. CDN asset و صفحه عمومی را نزدیک می‌کند، اما Checkout و API به origin و درگاه متصل‌اند. موقعیت دیتاسنتر را با کاربران، درگاه، قوانین داده و دسترسی عملیات بسنجید.
پایداری و Backup
Snapshot جای backup مستقل و آزمون restore را نمی‌گیرد. RPO میزان داده قابل از دست رفتن و RTO زمان بازیابی است. دیتابیس و media باید سازگار backup شوند. replica و HA بدون failover test فقط هزینه اضافه‌اند.
امنیت و عملیات روزمره
patch، SSH key، دسترسی حداقلی، firewall، TLS، secret management، log rotation و مانیتورینگ جزو ظرفیت عملیاتی‌اند. سرور سریع بدون patch یا backup مناسب نیست. هزینه on-call و زمان پاسخ incident را در مقایسه حساب کنید.
هزینه کل مالکیت را حساب کنید
قیمت ماهانه VM تنها بخشی از هزینه است. backup و storage، ترافیک خروجی، IP، لایسنس پنل، سرویس ایمیل، مانیتورینگ، زمان patch و on-call را اضافه کنید. پلن ارزان که هر incident چند ساعت نیروی فنی می‌خواهد ممکن است از گزینه مدیریت‌شده گران‌تر تمام شود.
در مقابل، سرویس مدیریت‌شده‌ای که دسترسی به log، export یا تنظیم لازم را نمی‌دهد نیز هزینه مهاجرت و محدودیت ایجاد می‌کند. محدوده SLA و مسئولیت هر لایه را کتبی و فنی بررسی کنید.
تعیین ظرفیت اولیه
- metric فعلی و سناریوی پیک را جمع کنید.
- مصرف PHP و زمان Query را بسنجید.
- نسبت cache hit و dynamic را محاسبه کنید.
- Load test مرحله‌ای اجرا کنید.
- نقطه اشباع را پیدا کنید.
- حاشیه رشد و failure اضافه کنید.
- پس از استقرار بازبینی کنید.
Scale Up یا Scale Out؟
افزایش منابع یک سرور ساده‌تر و معمولاً قدم اول است. چند node نیازمند session/cache مشترک، media هماهنگ، load balancer و deployment سازگار است. زمانی scale out کنید که bottleneck، availability و توان عملیاتی آن را توجیه کند.
حاشیه امن و Headroom
سرور نباید در ترافیک معمول دائماً نزدیک سقف باشد. headroom برای spike، cache miss، backup و failure یک worker لازم است. درصد ثابت جهانی وجود ندارد؛ زمان scale، نوسان workload و هزینه قطعی را در نظر بگیرید. هشدار باید پیش از saturation فرصت اقدام بدهد.
اگر مصرف CPU پایین ولی PHP queue بالا است، شاید request منتظر I/O یا API باشد. اگر RAM آزاد است اما storage latency جهش می‌کند، خرید RAM بیشتر اولویت نیست. headroom را برای هر منبع جدا بخوانید.
اندازه‌گیری مصرف هر Request
میانگین حافظه PHP را از یک صفحه cacheشده نگیرید. محصول، جست‌وجو و Checkout را جدا پروفایل کنید و پیک مصرف را در بودجه worker لحاظ کنید. memory leak یا افزونه‌ای که response را سنگین می‌کند با افزودن RAM فقط دیرتر دیده می‌شود.
محیط Staging و هزینه آن
staging لازم نیست همیشه هم‌اندازه production باشد، اما برای load test باید محدودیتش شناخته شود. استفاده از دیتابیس کوچک نتایج Query را خوش‌بینانه می‌کند. داده مشتری را بدون ناشناس‌سازی کپی نکنید و ایمیل/درگاه واقعی را در staging غیرفعال یا sandbox کنید.
قفل‌شدن به ارائه‌دهنده
سرویس مدیریت‌شده می‌تواند ارزشمند باشد، اما مسیر export دیتابیس، media، DNS و backup را از ابتدا بررسی کنید. خروج از provider نباید به فرمت اختصاصی بدون ابزار بازیابی وابسته باشد. هزینه egress، snapshot و IP را در برنامه مهاجرت لحاظ کنید.
رشد را دوره‌ای بازبینی کنید
اندازه مناسب امروز برای کمپین شش ماه بعد تضمین نیست. روند سفارش، کاتالوگ، variation، دیتابیس، media و jobها را ماهانه یا پس از release مهم مرور کنید. ظرفیت‌سنجی باید بر اساس تغییر workload به‌روزرسانی شود، نه اینکه فقط هنگام قطعی انجام شود.
فروش ویژه حاشیه امن جدا می‌خواهد
ظرفیت متوسط معیار کمپین نیست. spike، cache stampede، retry و jobهای پس از سفارش را لحاظ کنید. آماده‌سازی فروش ویژه runbook و روز اجرا را پوشش می‌دهد.
اشتباه‌های رایج
- انتخاب بر اساس تعداد محصول
- مقایسه فقط vCPU و RAM
- افزایش worker بدون حافظه
- VPS خام بدون مسئول عملیات
- نادیده گرفتن storage و backup
- scale پیش از رفع Query بد
- اعتماد به benchmark غیرمشابه
چه زمانی کمک تخصصی لازم است؟
اگر انتخاب سرور به مهاجرت، فروش ویژه یا چند node گره خورده، برآورد حدسی هزینه یا قطعی می‌سازد. پشتیبانی ووکامرس می‌تواند workload، PHP، دیتابیس و پرداخت را اندازه بگیرد و معماری متناسب پیشنهاد کند.
پرسش‌های متداول
چند گیگ RAM لازم است؟
به worker، دیتابیس، Redis، ترافیک و اندازه process بستگی دارد؛ عدد ثابت قابل دفاع نیست.
سرور ایران یا خارج؟
کاربر، درگاه، سرویس خارجی، قوانین و کیفیت مسیر را بسنجید.
آیا سرور اختصاصی لازم است؟
نه الزاماً؛ workload و نیاز isolation/operation تعیین‌کننده است.
Cloud یا VPS؟
Cloud انعطاف بیشتر ولی پیچیدگی و هزینه دارد. availability، تیم و رشد را مقایسه کنید.