Как выбрать сервер для интернет-магазина на 1С-Битрикс

Оцените собственные одновременные запросы, структуру каталога, интенсивность заказов, интеграции, поиск, фоновые задания, объём базы и пиковые сценарии. Затем воспроизведите нагрузку и проверьте метрики. Например, у Maxiplace доступны виртуальные серверы для 1С-Битрикс с подготовленным окружением, однако размер VPS следует подтверждать измерениями проекта.

Два магазина с одинаковой посещаемостью могут требовать разной мощности. Один показывает кешированные страницы, второй рассчитывает персональные цены, фильтрует множество предложений и обменивается данными с учётной системой. Поэтому универсальная таблица «посетители — процессоры — память» создаёт ложную точность.

До выбора тарифа соберите данные за обычные дни и периоды максимальной активности. Вам понадобятся загрузка CPU, использование RAM, задержки диска, размер базы, число соединений и время ответа страниц. Отдельно отметьте часы обменов, резервного копирования, переиндексации и рассылок.

Суточное число визитов плохо описывает нагрузку. Важнее, сколько динамических запросов приходит одновременно и как долго каждый выполняется. Кешированная карточка требует меньше вычислений, чем корзина, персональная цена, оформление заказа или сложный фильтр.

Разделите трафик на кешируемые и динамические страницы. Проверьте долю авторизованных пользователей и активность поисковых роботов. Статику и изображения можно отдавать через CDN, но база и персональная логика продолжат нагружать сервер приложения.

Нагрузку создаёт не только количество товаров в каталоге, но и предложения, свойства, типы цен, остатки, разделы и связи. Чем сложнее структура вашего ресурса, тем тяжелее выборки, фильтрация, импорт и построение кеша. Кроме того, объёмный каталог сложнее резервировать и восстанавливать. Так что проверьте запросы на копии базы, размер индексов и объём активно читаемых данных. Нужен запас RAM для ОС, PHP, базы и кешей одновременно. Если рабочие данные вытесняются на диск, добавление процессорных ядер проблему не решит.

Когда у вас много заказов, это выгодно, но на инфраструктуре плохо сказывается отсутствие интервалов. Одновременное оформление меняет корзины, резервы, остатки, платёжные статусы и служебные записи. При всплеске операции могут дольше ждать блокировок базы. Тестируйте полный путь: авторизация, корзина, доставка, оплата и создание заказа. Для платёжного сервиса используйте тестовый режим. Проверяйте скорость, отсутствие дублей, потерянных статусов и некорректных остатков.

Также обмен с 1С, CRM, маркетплейсами и службами доставки потребляет CPU, память, диск и соединения с базой. Выгрузка каталога в час пик может замедлить витрину. Сбой внешнего API способен создать очередь повторных попыток.

Зафиксируйте расписание, объём, частоту и допустимое время каждого обмена. Тяжёлые операции переносите на свободные часы, разбивайте на порции и ограничивайте параллелизм. Критичным интеграциям нужны журналы, мониторинг очередей и безопасный повтор без дублей.

Подсказки, фильтры и сортировка могут затрагивать множество товаров и свойств. Производительность зависит от структуры данных, индексов, настроек и реализации компонентов. Запишите популярные и тяжёлые запросы, включая пустой результат и сочетание фильтров. Измерьте время ответа и нагрузку на базу. Если оптимизация и кеширование не помогают, оцените отдельный поисковый сервис, учитывая синхронизацию индекса и сопровождение.

Агенты и задания cron отправляют письма, обновляют цены, строят отчёты, обрабатывают изображения и пересоздают кеш. Они незаметны, пока не совпадут между собой или с ростом трафика. Составьте реестр заданий с длительностью, частотой и владельцем. Разнесите тяжёлые процессы и контролируйте ошибки. Зависшее задание или очередь являются эксплуатационной проблемой, а добавление CPU лишь маскирует её.

Пики возникают после рассылки, запуска рекламы, публикации акции или массового обновления цен. Опасен не только высокий трафик, но и совпадение покупателей с импортом, индексированием либо бэкапом. Средняя загрузка такого риска не показывает. Проведите нагрузочный тест с реалистичной смесью просмотров, поиска, корзин и заказов. Увеличивайте интенсивность постепенно, наблюдая за временем ответа, ошибками, CPU, RAM и диском. Зафиксируйте предел стабильной работы и оставьте запас для роста, служебных процессов и непредсказуемых всплесков.

Сначала опишите пользовательские и фоновые сценарии. Затем соберите метрики, подготовьте копию проекта и протестируйте несколько конфигураций на одинаковой нагрузке. Выберите минимальный вариант, который выдерживает пик с запасом и сохраняет приемлемое время ответа. После запуска включите мониторинг и установите пороги масштабирования. Пересматривайте конфигурацию после изменений каталога, интеграций или рекламной активности: сервер выбирают не навсегда, а под измеряемую текущую задачу.