Лімітів на shared-хостингу більше, ніж ви думаєте: як знайти приховані обмеження до того, як вони знайдуть вас

Уявіть: ви купили квартиру в новобудові, заселились, розклали речі - і раптом дізнаєтесь, що душ можна приймати лише 15 хвилин на день, пральну машинку вмикати тільки до 20:00, а кондиціонер працює по черзі - спочатку у сусіда зліва, потім у вас. Абсурд? А тепер відкрийте умови вашого shared-хостингу і прочитайте дрібний шрифт. Там приблизно те саме, тільки замість води і електрики - процесорний час, оперативна пам'ять та IOPS. І якщо ви думаєте, що "необмежений" хостинг за $3 на місяць справді без лімітів - сядьте зручніше. Ця стаття збереже вам нерви, гроші і, можливо, весь бізнес.

Чому "необмежений" не означає те, що ви думаєте

Маркетинг хостинг-провайдерів - це окреме мистецтво. Слово "unlimited" на головній сторінці працює як магніт. Людина бачить "безліміт на диск" і вже уявляє, як заливає терабайти відео. Але реальність жорстка: у Terms of Service (які ніхто не читає) завжди є пункт про "fair usage policy" - політику справедливого використання.

Ось як це працює. Провайдер розміщує на одному фізичному сервері 200-500 акаунтів. Кожен з них ділить процесор, пам'ять, дисковий ввід-вивід. Якщо написати "ліміт CPU - 5%", клієнт не купить. А якщо написати "unlimited" і додати зірочку - купить, і ще друзям порекомендує.

"Shared hosting is like a bus. You paid for a seat, not for the entire vehicle. If you start spreading your luggage across three rows, the driver will ask you to leave." - Troy Hunt, відомий дослідник безпеки та автор Have I Been Pwned

Головне правило: якщо щось виглядає як необмежене за смішну ціну - це обмежене, просто вам поки що не показали де саме.

Карта прихованих лімітів: що обрізають першим

Я зібрав реальні обмеження, які зустрічаються у більшості shared-провайдерів. Деякі з них відкриті, деякі ви дізнаєтесь тільки коли сайт ляже.

Зверніть увагу на колонку "Entry processes". Це кількість одночасних з'єднань, які ваш сайт може обробити. Для WordPress з WooCommerce і 50 відвідувачами одночасно 20 процесів - це як один касир у супермаркеті в п'ятницю ввечері. Черга до горизонту, а кожен третій розвернеться і піде.

Inode - тихий вбивця, про якого мовчать

Диск може бути "безлімітний", але кількість файлів - ні. Кожен файл, кожна папка, кожен симлінк - це один inode. Типовий ліміт на shared-хостингу - від 100 000 до 250 000 inodes.

Звучить як багато? Давайте рахувати:

• Чистий WordPress - близько 10 000 файлів
• WordPress + 20 плагінів + тема - 30 000-50 000 файлів
• Плагін кешування (наприклад, WP Super Cache) може створити 20 000-100 000 файлів кешу
• Логи, тимчасові файли, бекапи в корені - ще 10 000-50 000
• Поштові скриньки з купою листів - по 1 inode на кожен лист

Один мій знайомий запустив інтернет-магазин на shared-хостингу. 8 000 товарів, по 5 фото на кожен, плюс генерація мініатюр різних розмірів. Через два місяці акаунт заблокували - 250 000 inodes вичерпані. А на диску було зайнято лише 4 ГБ з "необмежених".

Порада: перевіряйте кількість inodes раз на тиждень. У cPanel це займає 10 секунд. Краще видалити старий кеш самому, ніж з'ясовувати причину 500-ї помилки о третій ночі.

Як читати "дрібний шрифт" правильно

Перед покупкою shared-хостингу відкрийте три документи: Terms of Service, Acceptable Use Policy та Fair Usage Policy. Це нудно. Це довго. Це збереже вам гроші. Ось що шукати:

1. Ліміти CPU і RAM - якщо вказані конкретні цифри, це добрий знак. Провайдер чесний. Якщо написано "reasonable usage" без цифр - тікайте.
2. Inodes - шукайте конкретне число. Якщо не знайшли, напишіть у підтримку і попросіть назвати ліміт. Відповідь "у нас немає лімітів" - червоний прапорець.
3. Процедура при перевищенні - вам надішлють попередження? Або просто заблокують акаунт? Деякі провайдери дають 24 години на виправлення, інші блокують миттєво.
4. Ліміти на cron-завдання - мінімальний інтервал часто 15 хвилин, а не 1 хвилина. Якщо ваш проєкт потребує крон щохвилини - shared не для вас.
5. Обмеження на зовнішні з'єднання - деякі провайдери блокують вихідні з'єднання на нестандартні порти. Якщо ваш скрипт звертається до стороннього API через порт 8443, це може просто не працювати.

Один провайдер (не буду називати, бо адвокати не сплять) у своєму ToS мав пункт: "Company reserves the right to limit resources at its sole discretion without prior notice." Тобто можуть обрізати що завгодно, коли завгодно, без попередження. І ви з цим погодились, натиснувши "Accept".

CloudLinux LVE: ваш справжній контракт з провайдером

Більшість серйозних shared-хостингів працюють на CloudLinux з технологією LVE (Lightweight Virtual Environment). Це система, яка жорстко ізолює ресурси кожного акаунта. І ось тут починається правда.

CloudLinux LVE контролює:

• SPEED - процесорна потужність, вимірюється у відсотках від одного ядра (наприклад, 100% = одне повне ядро)
• PMEM - фізична пам'ять, типово 512 MB - 1 GB
• IO - швидкість читання/запису на диск, часто 2-4 MB/с (так, саме мегабайти, не гігабайти)
• EP - entry processes, ті самі одночасні з'єднання
• NPROC - загальна кількість процесів

Коли ваш сайт досягає будь-якого з цих лімітів, CloudLinux не вбиває процес одразу. Він ставить його в чергу. Відвідувач бачить повільне завантаження або помилку 508 (Resource Limit Reached). Сторінка, яка зазвичай відкривалася за 1.5 секунди, раптом вантажиться 12. Google це бачить, і ваші позиції повзуть вниз.

Якщо ваш провайдер надає доступ до Resource Usage у cPanel - дивіться туди регулярно. Там видно графіки: скільки разів за день ви досягли ліміту. Три-п'ять разів на тиждень - нормально. Тридцять разів на день - час переїжджати на VPS.

Як витиснути максимум зі своїх лімітів

Переходити на VPS дорого. Міняти провайдера - клопотно. Що можна зробити прямо зараз, щоб жити в межах своїх лімітів, але при цьому сайт працював нормально?

1. Увімкніть OPcache - PHP не буде перекомпілювати скрипти при кожному запиті. Економія CPU до 60%. У більшості shared-хостингів OPcache вже встановлений, його треба лише активувати через php.ini або MultiPHP Manager.
2. Використовуйте CDN - Cloudflare (безкоштовний план) забирає на себе статику: зображення, CSS, JS. Менше навантаження на ваш хостинг, менше Entry Processes, менше IO.
3. Оптимізуйте зображення - конвертуйте в WebP, стискайте до 80% якості. Один JPEG на 5 MB замість 200 KB - це злочин проти IOPS.
4. Обмежте cron-завдання - кожен крон з'їдає CPU і RAM. Якщо у вас WordPress з десятком плагінів, wp-cron може запускатися при кожному візиті. Вимкніть його і налаштуйте системний cron раз на 30 хвилин.
5. Чистіть кеш і логи - встановіть правило: раз на тиждень видаляти тимчасові файли. Автоматизуйте це тим самим кроном.
6. Перевірте плагіни - деякі плагіни WordPress роблять по 50 SQL-запитів на одне завантаження сторінки. Використовуйте Query Monitor, щоб знайти "пожирачів".

Ці шість кроків - не магія. Це гігієна. Як чистити зуби: нецікаво, але альтернатива набагато гірша.

Коли shared-хостинг вже не рятує

Є чіткі сигнали, що ви переросли shared. Не "може бути, колись", а "прямо зараз":

• Помилка 508 або 503 з'являється частіше двох разів на день
• Ваш сайт стабільно вантажиться довше 4 секунд, навіть з кешуванням і CDN
• Вам потрібен SSH для складних операцій, а провайдер не дає або обмежує
• Магазин обробляє більше 100 замовлень на день і кожен повільний запит - це втрачені гроші
• Ви витратили на оптимізацію вже більше, ніж коштує VPS на рік

Shared-хостинг - це не вирок і не компроміс для бідних. Це інструмент. Відмінний інструмент для блогів, портфоліо, невеликих бізнес-сайтів, лендінгів. Але коли ви намагаєтесь запустити на ньому навантажений SaaS або інтернет-магазин з тисячами SKU - це як возити піаніно на велосипеді. Технічно можливо. Практично - безглуздо.

Справжнє питання не в тому, хороший чи поганий ваш shared-хостинг. Питання в тому, чи знаєте ви його справжні межі - до того, як ваші клієнти покажуть вам їх у вигляді порожнього кошика і закритої вкладки браузера?