هاست می‌تواند عامل کندی باشد، اما عبارت «منابع نامحدود» یا یک نمودار CPU به تنهایی پاسخ نمی‌دهد. کد و زیرساخت روی هم اثر می‌گذارند: query بد روی سرور قوی هم هزینه دارد و هاست محدود می‌تواند کد سالم را در ساعات شلوغ throttle کند. پیش از مهاجرت باید محدودیت قابل تکرار را پیدا کنید.
پاسخ سریع: کندی را با زمان، URL و بار ثبت کنید؛ سپس CPU quota، throttling، RAM، I/O، PHP worker، connection دیتابیس، latency شبکه و uptime را از پنل یا پشتیبانی میزبان بگیرید. اگر bottleneck در چند آزمون کنترل‌شده و بدون تغییر کد تکرار شود، نقش هاست قابل دفاع‌تر است.
چه نشانه‌هایی هاست را جدی‌تر مطرح می‌کند؟
- کندی هم‌زمان چند endpoint dynamic در ساعت پرترافیک
- ثبت throttling یا رسیدن مکرر به CPU/entry process limit
- صف PHP worker با وجود requestهای سالم
- disk latency بالا یا محدودیت IOPS
- OOM، swap یا restart سرویس
- نوسان شدید شبکه یا downtime ثبت‌شده
- بهبود واضح همان clone روی محیط هم‌نسخه دیگر
بهبود پس از انتقال فقط وقتی شاهد خوبی است که نسخه PHP، cache، داده، ترافیک و تنظیمات تا حد ممکن یکسان باشند. مهاجرت معمولاً چند متغیر را هم‌زمان عوض می‌کند.
نشانه‌هایی که بیشتر به برنامه اشاره می‌کنند
کندی فقط یک صفحه، یک query، یک افزونه یا یک API خارجی معمولاً ابتدا نیاز به اصلاح application دارد. مصرف منابع بالا نیز ممکن است معلول bot، loop یا cron باشد. فرایند تشخیص کندی وردپرس محل زمان تلف‌شده را پیش از قضاوت مشخص می‌کند.
در هاست اشتراکی چه محدودیت‌هایی مهم‌اند؟
CPU time، RAM، entry process، concurrent connection، I/O، inode، cron frequency و PHP configuration را بررسی کنید. نام و روش گزارش این محدودیت‌ها بین providerها فرق دارد. رسیدن لحظه‌ای به سقف با اشباع پایدار یکسان نیست؛ نمودار timestampدار و log خطا لازم است.
در محیط اشتراکی ممکن است به slowlog یا تنظیمات کامل دسترسی نداشته باشید. از پشتیبانی بخواهید محدودیت اعمال‌شده، زمان و metric مربوط را دقیق اعلام کند، نه فقط توصیه کلی «پلن را ارتقا دهید».
PHP worker و صف درخواست
حتی با CPU آزاد، تعداد کم worker می‌تواند درخواست‌های dynamic را در صف نگه دارد. برعکس worker زیاد روی CPU/RAM محدود وضعیت را بدتر می‌کند. تعداد هم‌زمان کاربران، مدت request و ظرفیت هر worker را کنار هم بسنجید. cache عمومی فشار را کم می‌کند ولی checkout و wp-admin همچنان dynamic هستند.
Storage و دیتابیس
TTFB بالا همراه با iowait، query کند یا عملیات فایل می‌تواند به storage مربوط باشد. NVMe بودن نام دیسک تضمین latency ثابت در میزبان oversubscribed نیست. از metric و آزمون در زمان واقعی استفاده کنید. benchmark سنگین روی shared hosting بدون اجازه می‌تواند به دیگران آسیب بزند و خلاف شرایط سرویس باشد.
فاصله دیتابیس و شبکه
اگر وب و دیتابیس در شبکه دور یا DNS ناپایدارند، هر query و اتصال هزینه می‌گیرد. CDN فقط مسیر کاربر تا edge را بهتر می‌کند و latency داخلی origin را پنهان نمی‌کند. برای تحلیل TTFB وردپرس زمان DNS/TLS و backend را جدا ثبت کنید.
آزمون مقایسه‌ای منصفانه
- از سایت و دیتابیس backup بگیرید.
- clone را با نسخه PHP و extension مشابه بسازید.
- ایمیل، پرداخت و webhook محیط آزمایش را ایمن کنید.
- یک dataset و سناریوی ثابت انتخاب کنید.
- cache سرد و گرم و کاربران dynamic را جدا تست کنید.
- TTFB، throughput، error rate و منابع را ثبت کنید.
- تغییرات پیکربندی را مستند و نتیجه را چند بار تکرار کنید.
load test بدون سقف و هماهنگی روی production خطر قطعی و هزینه دارد. آن را در staging یا پنجره کنترل‌شده با stop condition اجرا کنید.
آیا باید پلن را ارتقا دهیم؟
اگر workload معتبر به سقف می‌رسد و کد، cache و queryها معقول‌اند، ارتقای ظرفیت منطقی است. اگر یک bot یا job خراب منابع را می‌بلعد، پلن بزرگ‌تر فقط زمان می‌خرد. هزینه مدیریت، backup، امنیت و مانیتورینگ را نیز در مقایسه shared hosting، managed VPS و VPS خودمدیریت وارد کنید.
ماندن، ارتقای پلن یا مهاجرت؟
| وضعیت | تصمیم محتمل | شرط تأیید |
|---|---|---|
| منابع کافی و یک query کند | ماندن و اصلاح برنامه | بهبود قابل‌اندازه‌گیری پس از اصلاح query |
| سقف پلن فقط در peak معتبر | ارتقای کنترل‌شده | پیش‌بینی ظرفیت و نبود workload معیوب |
| محدودیت ثابت و نبود ابزار لازم | بررسی مهاجرت | آزمون clone روی مقصد و برنامه rollback |
| نیاز به مدیریت کم | سرویس managed | SLA، backup و حدود مسئولیت روشن |
| نیاز به کنترل کامل | VPS خودمدیریت | توان امنیت، patch، مانیتورینگ و پاسخ‌گویی |
قیمت ماهانه تنها معیار نیست. زمان تیم برای نگهداری، هزینه حادثه، کیفیت backup، محل داده و امکان خروج از سرویس را نیز مقایسه کنید. مقصدی که benchmark کوتاه خوبی دارد ولی مانیتورینگ و restore قابل آزمون ندارد، الزاماً انتخاب حرفه‌ای نیست.
قبل از مهاجرت چه چیزی را مستند کنیم؟
نسخه PHP و extensionها، اندازه فایل و دیتابیس، DNS و TTL، cronها، ایمیل خروجی، cache، webhook و نیازهای storage را ثبت کنید. معیار پذیرش شامل TTFB صفحات dynamic، error rate، checkout و wp-admin باشد. بدون این فهرست ممکن است سرعت بهتر شود اما قابلیت تجاری دیگری از کار بیفتد.
چه اطلاعاتی از پشتیبانی هاست بخواهیم؟
- زمان و نوع resource limit یا throttling
- نسخه و handler PHP و تعداد worker/entry process
- memory limit و سقف واقعی حساب
- خطاهای storage، MySQL و restart
- امکان دسترسی به access/error log
- محدودیت cron، connection و backup
اشتباه‌های رایج
- مهاجرت بدون baseline و ناتوانی در مقایسه
- انتخاب فقط بر اساس RAM تبلیغ‌شده
- benchmark مخرب روی production
- نادیده گرفتن هزینه مدیریت VPS
- تغییر هم‌زمان نسخه PHP، cache و میزبان
- فرض اینکه CPU بالا حتماً کمبود سخت‌افزار است
چه زمانی بررسی تخصصی لازم است؟
اگر provider محدودیت روشنی گزارش نمی‌کند یا برنامه و زیرساخت هم‌زمان مشکوک‌اند، تصمیم مهاجرت بدون داده می‌تواند فقط هزینه را جابه‌جا کند. سرویس افزایش سرعت وردپرس می‌تواند bottleneck را پیش از انتخاب پلن یا سرور مستند کند.
پرسش‌های متداول
آیا VPS همیشه از هاست اشتراکی سریع‌تر است؟
خیر؛ پیکربندی، مدیریت، storage و workload تعیین‌کننده‌اند. VPS ضعیف یا بدتنظیم می‌تواند کندتر باشد.
آیا RAM بیشتر سرعت را بالا می‌برد؟
اگر فشار حافظه یا cache ناکافی bottleneck باشد؛ برای CPU، query یا API کند الزاماً نه.
آیا CDN ضعف هاست را جبران می‌کند؟
برای محتوای cacheشده کمک می‌کند، اما wp-admin، checkout و cache miss هنوز به origin وابسته‌اند.