مقایسهٔ کامل منابع هاست و بازدید؛ کدام برای شما مناسب است؟

سؤال پرتکرار مدیران این است: «با این بازدید، چه هاستی بخرم؟» جواب از فاکتور نمی‌آید؛ از پروفایل ترافیک می‌آید. میانگین بازدید اهمیت کمی دارد، اوج اهمیت دارد: دو سایت با بازدید روزانهٔ یکسان می‌توانند بار سروری کاملاً متفاوت بگذارند — یکی صفحه‌های سبکِ کش‌پذیر، دیگری سبد خرید، جستجو و عضویت. اسم «بازدید» هم گمراه‌کننده است: یک بازدید می‌تواند ده درخواست بسازد و هر درخواست مسیر پردازشی خودش را دارد؛ برای همین حرف اول و آخر را درخواست‌های هم‌زمان می‌زنند، نه شمارندهٔ بازدید.

سه مقالهٔ خواهر این بحث را از زوایای دیگر باز کرده‌اند: آموزش سنجش TTFB و سرعت سرور سنجش TTFB و لایه‌های کش را آموزش می‌دهد، مقایسهٔ کامل سرور مجازی برای وردپرس کلاس سرور مجازی را مقایسه می‌کند و CDN برای سایت‌های ایرانی لایهٔ توزیع برای مخاطب ایرانی را می‌چیند. این مقایسه سؤال مشترک آن‌ها را می‌گیرد: منابع چگونه به بازدید وصل می‌شوند و کِی باید کلاس عوض کنید. فهرست کامل موضوع‌های زیرساختی هم در هاب هاست و زیرساخت است.

منابع هاست و بازدید چگونه به هم گره می‌خورند؟

بار سرور با «تعداد بازدید روزانه» تعیین نمی‌شود؛ با «درخواست‌های هم‌زمان در ثانیه» تعیین می‌شود. ده هزار بازدید پخش‌شده در ۲۴ ساعت سبک است؛ همان ده هزار که در دو ساعت اوج فروش فشرده شود، ماشین را زیر فشار می‌برد. هر درخواست PHP برای اجرا مقداری رم و پردازنده می‌خواهد و تا تمام نشده، یک «پردازش در حال اجرا» حساب می‌شود؛ اینجاست که سقف‌های پنهان پلن‌ها معنا پیدا می‌کنند.

کش، معادله را عوض می‌کند: بازدیدی که به کش می‌خورد به PHP نمی‌رسد و منبع نمی‌گیرد؛ برای همین دو سایت با بازدید یکسان می‌توانند یکی راحت و دیگری نفس‌نفس‌زن باشند. برای اندازه‌گذاری، سه چیز را کنار هم بگذارید: وزن متوسط صفحه و کوئری‌هایش، شکل اوج (ساعتی و پیش‌بینی‌پذیر یا رویدادی مثل کمپین) و سهم بازدیدی که اصلاً قابل کش است — سبد خرید و حساب کاربری هرگز کش نمی‌شوند. یک ستون پنهان هم کراولرها هستند: بات‌های جستجو و اسکنرهای مزاحم در برخی شب‌ها بیشتر از کاربران واقعی درخواست می‌زنند؛ اگر لاگ سرور را نبینید، این بار را به گردن بازدید واقعی می‌اندازید و کلاس اشتباهی می‌خرید.

چهار منبع کلیدی که ترافیک مصرف می‌کند

منبع اول رم است؛ محل زندگی پردازش‌های PHP و کش سمت سرور. کمبود رم خودش را با کندی عمومی و نوسان زمان پاسخ نشان می‌دهد، نه با خطای روشن. منبع دوم پردازنده است؛ تولید صفحه، جستجوی داخلی و محاسبات سبد خرید این‌جا خرج می‌شود و کمبودش با صف طولانی و TTFB بالا در اوج خودش را نشان می‌دهد؛ روش سنجشش را در آموزش سرعت سرور ببینید.

منبع سوم، سقف پردازش هم‌زمان است — پنهان‌ترین و گمراه‌کننده‌ترین سقف پلن‌های اشتراکی. این سقف می‌گوید چند پردازش PHP می‌توانند هم‌زمان باز باشند؛ وقتی پر شود، درخواست‌های بعدی صف یا خطا می‌گیرند: سایت «بالا» است ولی جواب نمی‌دهد. منبع چهارم I/O و پهنای باند است؛ سرعت خواندن و نوشتن دیسک و حجم انتقال ماهانه. کمبود I/O در سایت‌های پرتصویر و شب‌های پشتیبان‌گیری خودش را نشان می‌دهد و پهنای باند کم، فایل‌های سنگین را در اوج ترافیک کُند می‌کند. چهار منبع را جدا نگه دارید و جدا بسنجید؛ بسته‌های فروش همیشه یک منبع را برجسته می‌کنند و همان یکی، گلوگاه بعدی شما نخواهد بود.

سه کلاس میزبانی در برابر سه کلاس بازدید

میزبانی اشتراکی منابع را با همسایه‌ها شریک می‌کند و برای سایت‌های سبکِ کش‌پذیر تا چند هزار بازدید روزانه منطقی است؛ مرزش معمولاً فضا نیست، سقف پردازش هم‌زمان و I/O است. سرور مجازی منابع رزروشده و ایزوله می‌دهد و جای فروشگاه متوسط، سایت محتوایی پرخواننده و مجموعه‌های چندسایته است؛ زمان درستِ انتخابش وقتی است که نشانه‌های اوج در اشتراکی تکرار شده باشند. ابری مقیاس‌پذیر با پرداخت بر اساس مصرف، اوج‌های متغیر، کمپین‌محورها و پلتفرم‌ها را جواب می‌دهد.

این سه کلاس جایگزین هم نیستند؛ مکمل‌اند. فروشگاه اوج‌محور در عمل ابری به‌علاوهٔ CDN به‌علاوهٔ کش سروری می‌خواهد، نه یکی از آن‌ها. برای مقایسهٔ دقیق کلاس میانی — سرور مجازی مدیریت‌شده در برابر نیمه‌مدیریت‌شده — جدول تصمیم مقالهٔ سرور مجازی وردپرس را ببینید و برای لایهٔ توزیع در شبکهٔ ایران، مقالهٔ CDN سایت‌های ایرانی نقش و مرزها را باز کرده است. برای مجموعه‌های چندسایته یادتان باشد منابع اشتراکی «منصفانه» نیستند: یک سایت نوزاد یا یک پنل سنگین می‌تواند سهم بقیه را بخورد و این را فقط با ایزوله‌سازی واقعی حل می‌کنید.

جدول اندازه‌گذاری کیفی؛ از وبلاگ تا فروشگاه اوج‌محور

اعداد جدول زیر تجربهٔ اجرایی ما از سایت‌های وردپرسی فارسی است، نه استاندارد صنعت؛ بازهٔ واقعی به وزن صفحه، تعداد کوئری و لایهٔ کش بستگی دارد. آن را نقطهٔ شروع گفت‌وگو با میزبان بگذارید، نه حکم نهایی: دو فروشگاه با بازدید یکسان می‌توانند دو کلاس مختلف بخواهند.

خواندن جدول با دادهٔ خودتان ساده است: ساعات اوج را از تحلیل بازدید در بیاورید، سهم صفحات سنگین مثل جستجو و پرداخت را حساب کنید و سهم قابل‌کش را تخمین بزنید. اگر سهم کش‌پذیر بالای نیمی از بازدید است، اول لایهٔ کش را کامل کنید؛ اگر سبد و حساب کاربری سهم بزرگی دارد، از همان ابتدا کلاس ایزوله را جدی بگیرید، چون آن بخش هرگز به کش نمی‌رود.

* تقریب تجربی ماست؛ وزن صفحه، کوئری‌ها و لایهٔ کش می‌تواند بازه را چندبرابر جابه‌جا کند.

نشانه‌های ارتقا؛ چه وقت جابه‌جا شوید؟

ارتقا را با تقویم تصمیم نگیرید؛ با نشانه‌ها بگیرید. سه نشانهٔ جدی: خطای ۵۰۳ یا ۵۰۸ و پیام «سقف منابع» در ساعات اوج؛ TTFBای که فقط در پیک بالا می‌رود و بقیهٔ روز سالم است؛ و خطای گام پرداخت در کمپین‌ها — گران‌ترین نشانهٔ ممکن، چون درست لحظهٔ فروش رخ می‌دهد. هر کدام از این سه را که دیدید، زمان‌بندی «فصل بعد» معنا ندارد؛ جلسهٔ همین هفته.

دو نشانهٔ نرم هم هست: کش که دیگر جواب نمی‌دهد و پشتیبان‌های شبانه که سایت روز بعد را کُند می‌کنند — نشانهٔ کمبود I/O. پیش از جابه‌جایی، یک دور بهینه‌سازی سمت نرم‌افزار را اجرا کنید: افزونه‌های سنگین، جستجوی پیش‌فرض سنگین و تصاویر بهینه‌نشده. به تجربهٔ ما همین دور کوتاه، گاهی ارتقا را یک کلاس عقب می‌اندازد و اگر نتواند، دست‌کم مشخص می‌کند که مشکل واقعاً زیرساخت است نه لایهٔ نرم‌افزار. تاریخ و ساعت ظاهرشدن نشانه‌ها را هم مکتوب کنید؛ الگوی «فقط پیک» در برابر «همیشه» خودش جواب کلاس بعدی را می‌دهد.

هزینه در بازار ایران؛ بازهٔ برآورد، نه عدد قطعی

بازه‌های سالانهٔ بازار که در راهنمای خواندن فاکتور هاست هم آمده: میزبانی اشتراکی معتبر حدود ۴۰۰ هزار تا ۲ میلیون تومان در سال؛ سرور مجازی و ابریِ مدیریت‌شده حدود ۶ تا ۲۰ میلیون تومان در سال. کلاس ابری مصرف‌محور فاکتور متغیر دارد: با اوج ترافیک بالا می‌رود؛ برای همین بودجه‌اش را با سقف مصرف و هشدار خودکار ببندید، وگرنه فاکتور ماه کمپین غافلگیر می‌کند.

به تجربهٔ ما هزینهٔ واقعی را رم تعیین نمی‌کند؛ نرخ تمدید، پشتیبان‌گیری و پشتیبانی تعیین می‌کنند، چون بخش عمدهٔ پرش‌های فاکتور مشتریان از همین سه آیتم آمده نه از خود منابع. هر استعلام را با سه پرسش ببندید: سقف پردازش هم‌زمان چند است؟ پشتیبان روزانه شامل پلن هست یا جدا فاکتور می‌شود؟ و تمدید چند درصد گران‌تر از قیمت معرفی است؟ هزینهٔ جابه‌جایی بین کلاس‌ها را هم در محاسبه بیاورید؛ کلاسی که دو ماه بعد دوباره باید عوض شود، ارزان‌تر از کلاسی نیست که یک پله جلوتر می‌ایستد.

جمع‌بندی؛ تصمیم با سه پرسش

پیش از خرید یا ارتقا، سه پرسش را جواب بدهید. اول: اوج من چه شکلی است — ساعتی و پیش‌بینی‌پذیر یا رویدادی و کمپین‌محور؟ دوم: کدام منبع اول تمام می‌شود — رم، پردازنده یا سقف هم‌زمانی؟ سوم: کلاس بعدی چه سقفی می‌دهد و تقریباً چه زمانی دوباره پر می‌شود؟ جواب این سه، هم پلن درست را تعیین می‌کند هم افق خرید بعدی را.

بعد از جابه‌جایی هم کار تمام نمی‌شود: یک هفتهٔ اول TTFB را در اوج بسنجید، لاگ خطا را ببینید و ظرفیت آزادشده را خرج کش بهتر کنید نه افزونهٔ تازه. سنجش زیرساخت را در چرخهٔ ماهانه نگه دارید؛ بازدید رشد می‌کند و معادله هر فصل عوض می‌شود. اگر نشانه‌ها را جمع کرده‌اید و تصمیم سخت است، ممیزی رایگان دامنه تصویر واقعی بار فعلی را می‌دهد و قابلیت‌های پلتفرم در قابلیت‌های پلتفرم انتشار و پایش خودکار را به همین چرخه وصل می‌کند.

رصد ما، رشد شما.