اگر منابع پلن میزبانی کمتر از نیاز سایت باشند، ممکن است با کندی، خطاهای سرویس و فشار روی CPU یا رم روبه‌رو شوید. از طرف دیگر، خرید منابعی که استفاده نمی‌شوند فقط هزینه را بیشتر می‌کند و لزوماً تغییری در عملکرد نمی‌دهد.
برای انتخاب مقدار مناسب پردازنده، رم، فضای ذخیره‌سازی و ظرفیت انتقال، باید بدانید سایت چه کاری انجام می‌دهد و در چه زمان‌هایی بیشترین بار را دارد. این راهنما نقش منابع و روش برآورد آن‌ها را توضیح می‌دهد تا انتخاب پلن صرفاً بر اساس تعداد بازدید نباشد.
سایت به چه مقدار منابع هاست نیاز دارد؟
پاسخ کوتاه این است که تعداد درخواست‌ها، هزینه پردازش هر درخواست و میزان هم‌زمانی، در کنار بازدید، نیاز منابع را تعیین می‌کنند. عدد بازدید روزانه به‌تنهایی برای انتخاب CPU و رم کافی نیست.
برای مثال، سایتی را فرض کنید که روزانه یک میلیون بازدید دارد و کاربران پس از ورود، هیچ کلیک یا فرم دیگری ثبت نمی‌کنند. حتی در این حالت نیز باز شدن صفحه و دریافت تصاویر، فایل‌ها و اسکریپت‌ها درخواست ایجاد می‌کند؛ بی‌حرکت ماندن کاربر به معنی نبود ترافیک نیست.
اگر صفحه از کش مرورگر یا CDN تحویل شود، ممکن است بخش زیادی از درخواست‌ها به سرور اصلی نرسد. در مقابل، صفحه پویا که برای هر بازدید کد و کوئری اجرا می‌کند، می‌تواند با همان تعداد بازدید منابع بیشتری مصرف کند.
بنابراین درخواست‌هایی که واقعاً به سرور می‌رسند و نوع پردازش آن‌ها اهمیت دارند. جدول زیر نمونه‌ای برای شروع بررسی و آزمون است، نه حداقل قطعی یا تضمین ظرفیت. در هاست اشتراکی نیز «هسته» و «رم» ممکن است سقف مصرف حساب باشند و با منابع یک VPS یکسان نباشند.
| نوع سایت | سناریوی فرضی ترافیک | CPU برای شروع آزمون | RAM برای شروع آزمون | فضای قابل بررسی |
|---|---|---|---|---|
| شرکتی یا لندینگ سبک | تا ۲۰ هزار بازدید ماهانه | ۱ تا ۲ هسته | ۱ تا ۲ گیگابایت | ۱۰ تا ۲۰ گیگابایت |
| وبلاگ متوسط | ۲۰ تا ۱۰۰ هزار بازدید ماهانه | ۲ تا ۴ هسته | ۲ تا ۴ گیگابایت | ۲۰ تا ۵۰ گیگابایت |
| فروشگاه کوچک | تا ۱۰۰ محصول و بار محدود | ۲ تا ۴ هسته | ۴ تا ۸ گیگابایت | از ۱۵ گیگابایت |
| فروشگاه متوسط | ۱۰۰ تا ۵۰۰ محصول و بار متوسط | ۴ تا ۸ هسته | حدود ۸ گیگابایت یا بیشتر | از ۵۰ گیگابایت |
| فروشگاه پرترافیک | نمونه‌ای با ۵۰ تا ۱۵۰ هزار بازدید ماهانه | ۶ تا ۸ هسته | ۸ تا ۱۶ گیگابایت | حدود ۱۰۰ گیگابایت یا بیشتر، در صورت نیاز محتوا |
| سایت پرترافیک یا SaaS | نمونه‌ای با بیش از ۵۰۰ هزار بازدید ماهانه | از ۸ هسته | ۱۶ تا ۳۲ گیگابایت | متناسب با داده و معماری |
این اعداد فقط فرض اولیه برای مقایسه‌اند. قاعده عمومی‌ای مانند «یک هسته و دو گیگ رم به‌ازای هر ۲۰۰ هزار بازدید» قابل اتکا نیست؛ کش، نوع برنامه و توزیع زمانی بار می‌توانند نتیجه را کاملاً تغییر دهند. مشخصات نهایی باید با پایش یا آزمون بار تعیین شوند.
هاست اختصاصی وردپرس
شروع از ماهانه 80 هزار تومان
منابع هاست چه وظیفه‌ای دارند؟
وقتی کاربر صفحه‌ای را باز می‌کند، درخواست شبکه ارسال می‌شود و ممکن است وب‌سرور، برنامه PHP یا Node.js و پایگاه داده در پاسخ‌گویی نقش داشته باشند. اگر پاسخ در کش موجود باشد، بخشی از پردازش تکراری حذف می‌شود؛ در غیر این صورت، صفحه باید ساخته شود.
در این مسیر، چهار دسته منبع اهمیت اصلی دارند.
CPU؛ پردازش درخواست‌ها
پردازنده دستورهای برنامه را اجرا می‌کند. اجرای PHP، پاسخ API، پردازش کوئری، ساخت صفحه پویا، تولید تصویر و ایجاد کش، هرکدام می‌توانند بخشی از توان CPU را مصرف کنند.
با افزایش درخواست‌های هم‌زمان، اگر پردازنده به سقف برسد، صف ایجاد می‌شود و زمان پاسخ بالا می‌رود. کافی بودن رم لزوماً این محدودیت را حل نمی‌کند. برای ارزیابی باید مصرف پردازنده را همراه نوع درخواست و زمان‌های اوج مشاهده کرد.
RAM؛ حافظه کاری سرور
رم محل نگهداری داده‌ها و وضعیت برنامه‌های در حال اجراست. کش‌ها، اطلاعات فعال پایگاه داده و در بعضی پیکربندی‌ها نشست کاربران در حافظه نگهداری می‌شوند تا دسترسی سریع‌تر باشد. همه این داده‌ها در تمام سیستم‌ها الزاماً در رم ذخیره نمی‌شوند و پیاده‌سازی اهمیت دارد.
وقتی حافظه کم شود، سیستم ممکن است از Swap استفاده کند یا با محدودیت حافظه و توقف پردازش روبه‌رو شود. دسترسی به Swap معمولاً از رم کندتر است و استفاده سنگین از آن می‌تواند عملکرد را پایین بیاورد. خطاهای ۵۰۰ یا ۵۰۳ ممکن است همراه این وضعیت دیده شوند، اما علت آن‌ها همیشه کمبود رم نیست.
فضای ذخیره‌سازی
فایل‌های سایت، پایگاه داده، تصاویر، لاگ‌ها و بعضی بکاپ‌ها روی دیسک قرار می‌گیرند. ظرفیت کافی برای جلوگیری از پر شدن فضا لازم است، اما سرعت خواندن و نوشتن هم به‌خصوص در برنامه‌های وابسته به پایگاه داده اهمیت دارد.
سرور مجازی ارزان
شروع از ماهانه 100 هزارتومان
علاوه بر ظرفیت، نوع درایو و سقف ورودی و خروجی پلن را بررسی کنید. NVMe نوعی پروتکل است که در SSDها استفاده می‌شود؛ بنابراین مقایسه دقیق‌تر، مثلاً میان SATA SSD و NVMe SSD است، نه NVMe در برابر تمام SSDها. NVMe نیز به‌خودی‌خود امنیت بیشتر ایجاد نمی‌کند.
عددی مثل ۴۰۰۰ مگابایت‌برثانیه یا نسبت ثابت ده‌برابر برای همه درایوها معتبر نیست. سرعت به مدل، نسل رابط، الگوی دسترسی و محدودیت حساب بستگی دارد؛ دسترسی تصادفی پایگاه داده با انتقال پیوسته فایل یکسان نیست.
HDD نیز به‌طور کلی منسوخ نشده و برای بعضی کاربردهای آرشیوی اقتصادی است. برای وب‌سایت دارای درخواست‌های تصادفی زیاد، SSD اغلب انتخاب مناسب‌تری است، اما کیفیت زیرساخت را باید از مجموعه مشخصات و عملکرد سنجید، نه فقط یک نام.
پهنای باند و حجم انتقال
پهنای باند یا ظرفیت اتصال، میزان داده قابل انتقال در واحد زمان را نشان می‌دهد. ترافیک ماهانه، حجم مجموع داده منتقل‌شده در دوره است. باز شدن صفحه، دانلود تصویر و پخش ویدئو در این مصرف نقش دارند. محدودیت هرکدام می‌تواند نتیجه متفاوتی ایجاد کند و باید جدا بررسی شوند.
برای برآورد اولیه حجم انتقال ماهانه می‌توان از این رابطه استفاده کرد:
حجم انتقال ماهانه ≈ تعداد بارگذاری صفحه در ماه × میانگین حجم منتقل‌شده هر صفحه
- یک لندینگ سبک ممکن است حدود ۰٫۵ تا ۱ مگابایت داده منتقل کند.
- یک صفحه وبلاگ همراه تصویر ممکن است حدود ۱ تا ۳ مگابایت باشد.
- صفحه فروشگاهی با تصاویر محصول ممکن است حدود ۲ تا ۵ مگابایت انتقال داشته باشد.
این بازه‌ها مثال‌اند و باید حجم واقعی سایت اندازه‌گیری شود. اگر ۳۰ هزار بارگذاری صفحه در ماه داشته باشید و هر بار ۲ مگابایت منتقل شود، برآورد ساده حدود ۶۰ گیگابایت است. کش مرورگر و CDN می‌توانند انتقال از مبدأ را کاهش دهند، اما بارگیری فایل‌ها، ربات‌ها و سایر درخواست‌ها هم باید در محاسبه دیده شوند.
سرور مجازی ویندوز
Remote Access & Full Admin
چرا مصرف منابع سایت‌ها متفاوت است؟
دو سایت با بازدید یکسان ممکن است مصرف کاملاً متفاوتی داشته باشند. برای فهم این تفاوت، نوع برنامه و نحوه رسیدگی به درخواست‌ها را بررسی کنید.
۱. نوع سایت
یک سایت شرکتی ساده معمولاً با فروشگاه ووکامرسی رفتار یکسانی ندارد. تعداد صفحات به‌تنهایی معیار نیست؛ کاری که در هر درخواست انجام می‌شود مهم‌تر است.
سبد خرید، فیلتر کالا، جست‌وجو، کاربران واردشده و کوئری‌های سنگین می‌توانند بار فروشگاه را بیشتر کنند. بعضی از این پاسخ‌ها نیز نباید مانند صفحه عمومی کش شوند، چون اطلاعات اختصاصی کاربر دارند.
به همین دلیل، فروشگاه ممکن است از یک سایت محتوایی هم‌ترافیک منابع بیشتری بخواهد. نسبت ثابتی مانند ۱٫۵ یا ۲ برابر برای همه فروشگاه‌ها معتبر نیست و باید مصرف همان پروژه اندازه‌گیری شود.
۲. توزیع ترافیک و هم‌زمانی
علاوه بر تعداد بازدید، مهم است چند درخواست در یک بازه کوتاه به سرور می‌رسند و پردازش هرکدام چقدر طول می‌کشد.
برای نمونه، ۲۰ هزار بازدید که در تمام روز پخش شده‌اند با همان تعداد مراجعه در چند دقیقه یک کمپین برابر نیستند. حالت دوم می‌تواند صف درخواست و فشار بیشتری ایجاد کند، حتی اگر مجموع بازدید روزانه تغییر نکرده باشد.
پس برای انتخاب منابع، زمان اوج و تعداد کاربران هم‌زمان را نیز ثبت کنید. میانگین روزانه ممکن است نیاز واقعی در ساعت شلوغ را پنهان کند.
۳. کیفیت کش
کش می‌تواند از اجرای دوباره کارهای مشابه جلوگیری کند و مصرف منابع را پایین بیاورد. نوع کش باید با داده و رفتار برنامه هماهنگ باشد.
ابزارهایی مانند LiteSpeed Cache، Redis، کش اشیا و CDN وظایف یکسانی ندارند، اما تنظیم درست آن‌ها می‌تواند بار مبدأ را کاهش دهد. میزان بهبود به سایت بستگی دارد و نمی‌توان کاهش مصرف به نصف را برای همه تضمین کرد. کش اشتباه نیز ممکن است داده قدیمی یا اطلاعات کاربر دیگر را نمایش دهد.
۴. افزونه‌ها و قالب‌ها
قالب یا افزونه‌ای که کوئری زیاد، پردازش سنگین یا کار پس‌زمینه نامناسب ایجاد کند، می‌تواند CPU و رم را درگیر کند. صفحه‌ساز، آمارگیر و ابزار امنیتی باید بر اساس رفتار واقعی بررسی شوند، نه اینکه صرفاً نام یک گروه را علت کندی بدانیم.
بکاپ‌گیری فشرده یا هم‌زمان با اوج مراجعه نیز ممکن است بار اضافی ایجاد کند. زمان‌بندی و تنظیم درست، همراه با حذف قابلیت‌های غیرضروری، گاهی از ارتقای سخت‌افزار مؤثرتر است.
۵. نسخه PHP
نسخه‌های جدید و پشتیبانی‌شده PHP ممکن است نسبت به نسخه‌های قدیمی، بهبود کارایی و امنیت داشته باشند، اما درصد افزایش درخواست یا سرعت صفحه برای همه سایت‌ها یکسان نیست. پیش از تغییر، سازگاری وردپرس، قالب و افزونه‌ها را در محیط آزمایشی بررسی کنید و بکاپ و مسیر بازگشت داشته باشید. نسخه را صرفاً با تکیه بر یک بنچمارک عمومی روی سایت اصلی تغییر ندهید.
برآورد منابع برای انواع سایت
بازه‌های زیر نمونه شروع ارزیابی هستند و تضمین عملکرد یا حداقل رسمی محسوب نمی‌شوند. در مقایسه پلن‌های میزبانی وب، علاوه بر اعداد، محدودیت پردازش هم‌زمان، I/O و نوع تخصیص منابع را بخوانید.
سایت شرکتی یا لندینگ سبک
صفحات محدود و نبود عملیات سنگین پایگاه داده می‌تواند مصرف این سایت‌ها را پایین نگه دارد. یک پلن ابتدایی ممکن است کافی باشد، به شرط آنکه قالب و امکانات جانبی سبک و متناسب باشند.
کش مناسب نیز می‌تواند پاسخ‌گویی به بازدید بیشتر را آسان‌تر کند، اما ظرفیت دقیق باید با الگوی مراجعه همان سایت سنجیده شود.
نمونه منابع برای شروع آزمون:
- CPU: یک تا دو هسته یا سهم پردازش معادل آن در قرارداد.
- RAM: یک تا دو گیگابایت.
- فضای ذخیره‌سازی: ۱۰ تا ۲۰ گیگابایت، در صورت تناسب با فایل‌ها.
وبلاگ با بازدید متوسط
انتشار مداوم، تصاویر و افزونه‌های جانبی ممکن است ظرفیت بیشتری بخواهند. حجم فایل‌ها و تعداد درخواست‌های بدون کش را کنار بازدید بررسی کنید.
نمونه منابع برای شروع آزمون:
- CPU: دو تا چهار هسته.
- RAM: دو تا چهار گیگابایت.
- فضای ذخیره‌سازی: ۲۰ تا ۵۰ گیگابایت، متناسب با رسانه‌ها.
فروشگاه ووکامرسی
فروشگاه به دلیل عملیات پویا ممکن است از وبلاگ مشابه پرمصرف‌تر باشد، اما تعداد محصول به‌تنهایی نیاز منابع را تعیین نمی‌کند. بازدید هم‌زمان، جست‌وجو و افزونه‌ها نیز مهم‌اند.
نمونه فروشگاه کوچک با حداکثر حدود ۱۰۰ محصول و بار محدود:
- CPU: دو تا چهار هسته.
- RAM: حدود چهار گیگابایت برای شروع ارزیابی، با امکان افزایش.
- فضای ذخیره‌سازی: از ۱۵ گیگابایت، بسته به حجم تصاویر و داده.
نمونه فروشگاه متوسط با حدود ۱۰۰ تا ۵۰۰ محصول:
- CPU: چهار تا هشت هسته.
- RAM: حدود هشت گیگابایت یا بیشتر، در صورت نیاز واقعی.
- فضای ذخیره‌سازی: حدود ۵۰ گیگابایت یا بیشتر، متناسب با محتوا.
نمونه فروشگاه پرترافیک با حدود ۵۰ تا ۱۵۰ هزار بازدید ماهانه:
- CPU: شش تا هشت هسته برای آزمون اولیه.
- RAM: حدود هشت تا ۱۶ گیگابایت، سپس تنظیم بر اساس پایش.
- فضای ذخیره‌سازی: حدود ۱۰۰ گیگابایت یا بیشتر فقط اگر حجم داده آن را توجیه کند.
هیچ‌کدام از این مقادیر استاندارد همگانی ووکامرس نیستند. ممکن است سایتی با منابع کمتر خوب کار کند یا سایتی با بازدید مشابه به منابع بیشتری نیاز داشته باشد. برای تشخیص، محدودیت‌ها و مصرف اوج را اندازه بگیرید.
سایت پرترافیک یا SaaS
در این پروژه‌ها، درخواست هم‌زمان، API و پایگاه داده می‌توانند بار زیادی بسازند. Redis، CDN، توزیع بار یا جداسازی پایگاه داده ممکن است لازم شوند، اما نیاز به هرکدام باید از معماری و اندازه‌گیری نتیجه شود.
نمونه منابع برای شروع بررسی:
- CPU: هشت هسته یا بیشتر، متناسب با قابلیت پردازش موازی برنامه.
- RAM: ممکن است از هشت تا ۱۶ گیگابایت شروع شود یا برای بار سنگین به ۱۶ تا ۳۲ گیگابایت و بیشتر برسد؛ عدد نهایی با آزمون تعیین می‌شود.
چه زمانی منابع هاست را ارتقا دهیم؟
اگر سایت کند شده، نشانه‌های زیر می‌توانند نیاز به بررسی منابع را نشان دهند:
- افزایش زمان پاسخ اولیه یا TTFB؛
- خطاهای ۵۰۳؛
- رسیدن طولانی‌مدت CPU به سقف مجاز؛
- کندی پنل مدیریت؛
- توقف یا خرابی سرویس MySQL؛
- خطاهای Out of Memory؛
- استفاده سنگین از Swap؛
- راه‌اندازی مجدد ناخواسته سرویس‌ها؛
- افت عملکرد هنگام افزایش کاربران هم‌زمان.
این نشانه‌ها به‌تنهایی کمبود CPU یا رم را ثابت نمی‌کنند. خطای برنامه، کوئری کند، حمله یا محدودیت دیسک نیز ممکن است علت باشد. ابتدا لاگ و نمودار مصرف را بررسی کنید؛ راهنمای مصرف بالای CPU سرور می‌تواند در جدا کردن علت‌ها کمک کند. اگر پس از بهینه‌سازی، محدودیت منابع همچنان گلوگاه است، ارتقا منطقی‌تر خواهد بود.
جمع‌بندی
نوع سایت، بار واقعی و کیفیت کش سه ورودی مهم برای انتخاب پلن هستند. منابع را با اندازه‌گیری و مسیر رشد پروژه هماهنگ کنید، نه با یک نسبت ثابت میان بازدید و رم.
برای شروع تصمیم‌گیری:
- در سایت سبک، حدود دو گیگابایت رم می‌تواند یکی از نقاط شروع آزمون باشد، نه الزام عمومی.
- در فروشگاه، ظرفیت حافظه را بر اساس بار پویا و افزونه‌ها بسنجید؛ چهار گیگابایت یا هر عدد دیگری تضمین کافی بودن نیست.
- پیش از ارتقا، کش، برنامه و پایگاه داده را بررسی کنید؛ علت کندی همیشه کمبود منابع نیست.
- شرایط ارتقای پلن و نیاز احتمالی به مهاجرت یا توقف را از قبل بدانید تا رشد سایت غافلگیرکننده نباشد.
اگر درباره انتخاب پلن سؤال دارید، نوع سایت و داده‌های مصرف فعلی را همراه پرسش مطرح کنید تا ارزیابی بر اساس اطلاعات واقعی انجام شود.
