Выбор тарифа хостинга "на глаз" — частая причина либо переплаты за неиспользуемые ресурсы, либо, что хуже, нехватки мощности в самый неподходящий момент вроде рекламной акции. Разберём, как посчитать реальную потребность сайта на 1С-Битрикс в ресурсах сервера, а не гадать по названию тарифа.
Что реально потребляет ресурсы
Основные потребители вычислительных ресурсов Битрикса — PHP-FPM (обработка запросов) и MySQL (запросы к базе). Статические файлы (изображения, CSS, JS) отдаются веб-сервером напрямую с минимальной нагрузкой на PHP, если правильно настроено кеширование и раздача статики. Расчёт тарифа стоит вести именно от нагрузки на эти два компонента, а не от общего абстрактного "трафика сайта".
Оценка через количество посетителей и время генерации страницы
Пиковые одновременные запросы ≈ (посетителей в час × среднее время
на странице в секундах) / 3600Грубая оценка пиковой нагрузки строится от числа одновременных посетителей, а не от общего трафика за день, — сайт с 10 000 визитов в день, равномерно распределённых по 24 часам, создаёт совсем другую нагрузку, чем тот же трафик, сконцентрированный в двухчасовой пик вечером.
Нужна помощь с Битрикс?
Роль кеширования в снижении требований к ресурсам
Полноценно настроенное кеширование страниц (композитный сайт, кеш компонентов) кардинально снижает требования к ресурсам — закешированная страница отдаётся почти без нагрузки на PHP и MySQL, тогда как некешированная генерируется заново на каждый визит. Расчёт тарифа без учёта реального состояния кеша на сайте либо завышает нужные ресурсы для хорошо закешированного проекта, либо катастрофически занижает их для сайта, где кеш почти не используется.
Нагрузочное тестирование вместо теоретического расчёта
# пример инструмента нагрузочного тестирования
ab -n 1000 -c 50 https://staging.example.ru/catalog/Теоретические формулы дают лишь приблизительную оценку — реальное нагрузочное тестирование на копии сайта (staging-окружении, а не на боевом сервере с реальными посетителями) показывает фактический предел конкретного тарифа для конкретного набора страниц и логики проекта, что заметно точнее любой универсальной формулы.
Пиковые нагрузки: акции, реклама, сезонность
Тариф стоит рассчитывать не на среднюю нагрузку, а на реалистичный пик — распродажа, запуск рекламной кампании или сезонный всплеск (например, предновогодние заказы для интернет-магазина подарков) создают трафик в разы выше обычного среднего дня. Возможность временного масштабирования ресурсов на период пика — важный критерий выбора хостинга наравне с базовым тарифом под обычную нагрузку.
Отдельный расчёт для базы данных
Требования к ресурсам базы данных растут с объёмом каталога и историей заказов не линейно с посещаемостью — крупный каталог с активным умным фильтром создаёт нагрузку на MySQL даже при умеренном трафике, если запросы недостаточно оптимизированы. Оценка тарифа должна учитывать не только посещаемость, но и реальный объём и сложность данных, с которыми работает MySQL.
Мониторинг после запуска как проверка расчёта
Любой предварительный расчёт — это оценка, а не гарантия, — после запуска на выбранном тарифе стоит мониторить реальное потребление ресурсов (загрузку CPU, использование памяти, время ответа сервера) и корректировать тариф по факту, а не считать первоначальный расчёт окончательным решением, актуальным навсегда без пересмотра по мере роста проекта.
Частые ошибки
- Расчёт ведётся от общего дневного трафика, а не от пиковой нагрузки. Тариф не выдерживает реальный концентрированный пик посещаемости.
- Не учтено состояние кеширования сайта. Заниженная или завышенная оценка требуемых ресурсов относительно реальности.
- Расчёт не пересматривается по мере роста проекта. Тариф, подходящий на старте, со временем перестаёт соответствовать реальной нагрузке.
Итог
Расчёт тарифа хостинга под сайт на 1С-Битрикс строится от реальной пиковой нагрузки на PHP-FPM и MySQL, с учётом того, насколько эффективно настроено кеширование, а не от абстрактного общего трафика. Нагрузочное тестирование на копии сайта даёт точную оценку предела конкретного тарифа, а мониторинг после запуска позволяет скорректировать выбор по факту, а не полагаться на разовый предварительный расчёт навсегда.