نمایندگی هاست چند سایت را جواب می‌دهد؟ ظرفیت واقعی را چطور بسنجیم؟

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

یک سایت معرفی شرکت با چند صفحه، یک وبلاگ تصویری و یک فروشگاه ووکامرس مصرف یکسانی ندارند. برای فروش و نگهداری درست نمایندگی، بهتر است هم فضای فروخته‌شده را بشناسیم و هم منابعی را که مشتریان واقعاً استفاده می‌کنند.

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

مثلاً یک مشتری هر شب فایل‌های زیادی وارد می‌کند، دیگری هنگام تبلیغ بازدید ناگهانی دارد و فروشگاه سوم مرتب موجودی را همگام می‌کند. این اطلاعات کمک می‌کنند بفهمید چرا بعضی ساعت‌ها سرویس تحت فشار قرار می‌گیرد، حتی وقتی فضای دیسک هنوز پر نشده است.

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

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

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

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

در بعضی محیط‌ها، مانند سرویس‌های مبتنی بر CloudLinux، برای هر حساب محدودیت منابع اعمال می‌شود. این محدودیت کمک می‌کند یک سایت همهٔ سرویس را درگیر نکند، ولی رسیدن همان حساب به سقفش می‌تواند باعث کندی یا خطا شود. توضیح محدودیت‌ها در مستندات CloudLinux

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

محدودیت اجرای هم‌زمان نیز اهمیت دارد. تعداد کاربران فعال، کارهای PHP و پردازش‌های پس‌زمینه می‌توانند بر آن اثر بگذارند. معنی ستون‌های پنل را از راهنمای همان سرویس بگیرید؛ نام مشابه در دو پلن الزاماً سیاست یکسانی ندارد.

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

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

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

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

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