У интернет-магазина с большим каталогом нагрузку создаёт не само число карточек. Один проект хранит сотни тысяч товаров, но меняет остатки раз в сутки и получает умеренный трафик. Другой имеет меньший каталог, однако одновременно запускает рекламные кампании, пересчитывает персональные цены, обменивается данными с 1С и строит сложный фильтр. Второму может требоваться заметно более серьёзная инфраструктура.
Поэтому хостинг выбирают не по обещанию «подходит для магазина» и не по одному объёму диска. Сначала описывают профиль нагрузки, затем проверяют архитектуру и только после этого подбирают CPU, память, диск, базу, кеширование и резервирование.
Содержание:
Сначала соберите профиль нагрузки магазина
Техническому специалисту недостаточно фразы «у нас 100 тысяч товаров». Нужны сведения о количестве активных товаров и предложений, свойствах и ценах, частоте изменений, размере изображений, числе посетителей, пиковых рекламных периодах и работе интеграций.
- сколько товаров, торговых предложений, ценовых типов и складов реально участвует в выдаче;
- сколько свойств используется в фильтре и как часто они пересчитываются;
- как часто загружаются остатки, цены, фотографии и описания;
- сколько заказов и одновременных пользователей бывает в обычный час и на пике;
- есть ли персональные цены, кабинеты контрагентов, бонусная система и расчёт доставки;
- какие операции выполняются синхронно, а какие можно перенести в очередь.
Лучше брать эти данные из аналитики, журналов сервера, мониторинга базы и истории обменов. Если магазин ещё не запущен, используют прогноз по рекламному бюджету и бизнес-процессам, а затем проверяют его нагрузочным тестом.
Какие операции создают основную нагрузку
| Операция | Что чаще всего ограничивает | Что измерять |
|---|---|---|
| Открытие категорий и карточек | PHP, кеш и обращения к базе | TTFB, время генерации, cache hit ratio |
| Фильтр и сортировка | Запросы к базе или поисковому индексу | Время запроса, число просмотренных строк, блокировки |
| Поиск по каталогу | Индекс и морфология | Задержку ответа и актуальность индекса |
| Импорт из 1С, ERP или PIM | CPU, диск и массовые записи в базу | Длительность пакета, очередь, блокировки, ошибки |
| Оформление заказа | База, платёжный шлюз, доставка, CRM | Время шага, тайм-ауты, повторные операции |
| Выдача изображений | Диск, сеть и размеры файлов | Объём трафика, скорость CDN, долю кеша |
Эта таблица помогает не покупать ресурсы вслепую. Например, увеличение оперативной памяти не исправит неиндексированный запрос, а дополнительные ядра не ускорят ожидание медленного API службы доставки.
Виртуальный хостинг, VPS или отдельная инфраструктура
| Вариант | Когда рассматривать | Основное ограничение |
|---|---|---|
| Виртуальный хостинг | Небольшой магазин с простой логикой, умеренным трафиком и редкими обменами | Мало контроля над окружением и общие лимиты площадки |
| VPS/VDS | Растущий магазин, которому нужны свои версии ПО, Redis, очереди и предсказуемые ресурсы | Администрирование и мониторинг становятся ответственностью владельца проекта |
| Выделенный сервер | Стабильно высокая нагрузка, большой объём данных или необходимость изоляции | Один сервер всё равно остаётся единой точкой отказа без резервирования |
| Несколько узлов или облачная архитектура | Критичные продажи, выраженные пики, B2B-функции и требования к отказоустойчивости | Больше стоимость и сложность сопровождения |
Магазин необязательно сразу переносить на несколько серверов. Архитектуру усложняют тогда, когда есть измеримая потребность: не помещается рабочий набор базы, фоновые задачи мешают покупателям, вертикальное увеличение ресурсов перестало помогать или бизнес не может принимать риск отказа одного узла.
Для простого проекта можно сначала сравнить тарифы виртуального хостинга для сайтов. Если нужны управляемые ресурсы, отдельное окружение и возможность масштабирования, полезнее смотреть конфигурации VPS/VDS для интернет-магазина. Конкретный тариф выбирают после замеров, а не только по числу товаров.
На что смотреть в процессоре, памяти и диске
Процессор важен для PHP, формирования страниц, импорта, обработки изображений и фоновых задач. Для отклика отдельного запроса имеет значение производительность ядра, а для параллельной нагрузки — доступное число ядер и правильная настройка процессов.
Оперативная память нужна приложению, базе, Redis, поисковому движку и системным службам. Если активные данные базы не помещаются в память, сервер начинает чаще обращаться к диску. Если включается swap, задержки могут резко вырасти.
Быстрый SSD или NVMe особенно заметен при случайных операциях базы, импортах и больших объёмах мелких файлов. Но маркировка накопителя не заменяет проверку IOPS, задержки, реальной производительности площадки и резервирования.
Нужно оставить запас на пики, резервные задания и обновления. Сервер, который в обычный день постоянно занят на 90–100%, не имеет пространства для рекламной кампании или внезапного импорта.
База данных, поиск и фильтр важнее объёма диска
Большой каталог предъявляет требования к схеме данных и запросам. Проверяют индексы, медленные запросы, размер активных таблиц, временные таблицы, блокировки, очистку служебных данных и параметры СУБД. Иногда оптимизация одного запроса даёт больше, чем переход на следующий тариф.
Фильтр особенно чувствителен к количеству свойств и сочетаний. Если CMS при каждом запросе перебирает слишком много строк, дополнительный CPU лишь ненадолго маскирует проблему. Для сложного поиска и фильтра может использоваться отдельный индекс — Elasticsearch, OpenSearch, Sphinx или механизм самой платформы. Это архитектурное решение, а не обязательная покупка для любого каталога.
Отделять базу на отдельный сервер следует не «для солидности», а при понятной причине: конкуренция за ресурсы, требования к репликации, рост объёма, необходимость независимого масштабирования или отказоустойчивость.
Как учитывать обмен с 1С, ERP, CRM и маркетплейсами
Частая проблема большого магазина — не посетители, а массовый обмен. Полная выгрузка одновременно меняет тысячи записей, строит свойства, создаёт изображения и сбрасывает кеш. В это время каталог может отвечать медленнее, а покупатель — видеть промежуточные данные.
- делить импорт на контролируемые пакеты;
- передавать только изменившиеся сущности, если это поддерживает источник;
- тяжёлые этапы выполнять через очередь и ограничивать их параллельность;
- разносить полный обмен и резервное копирование по времени;
- не очищать весь кеш, если можно инвалидировать только изменённые данные;
- вести журнал ошибок, длительности и объёма каждого обмена.
Для проектов на 1С-Битрикс дополнительно проверяют параметры компонентов, управляемый и тегированный кеш, работу агентов и cron, состояние индексов и сценарий CommerceML. Для другой CMS набор инструментов будет отличаться, но принцип тот же: обмен не должен бесконтрольно конкурировать с покупателями.
Кеширование, CDN и работа с изображениями
Кеш снижает количество повторных вычислений, но у магазина нельзя одинаково кешировать всё. Категории и карточки могут отдаваться из page cache, тогда как корзина, остатки, цены пользователя и личный кабинет требуют корректной персонализации.
| Уровень | Что ускоряет | Что важно проверить |
|---|---|---|
| OPcache | Исполнение PHP-кода | Размер кеша и отсутствие постоянных сбросов |
| Объектный кеш Redis/Memcached | Повторные данные и запросы CMS | Ключи, время жизни и инвалидирование |
| Кеш страниц | Категории, карточки, информационные страницы | Исключения для корзины, кабинета и персональных цен |
| CDN | Изображения, CSS, JavaScript | Обновление файлов и корректные cache headers |
| Поисковый индекс | Поиск и сложный фильтр | Скорость и задержку актуализации данных |
Изображения лучше заранее приводить к нужным размерам и современным форматам. Для очень большого медиакаталога рассматривают объектное хранилище и CDN, чтобы файлы не конкурировали с базой и PHP за диск и сеть.
Резервирование, копии и восстановление
Интернет-магазин должен переживать не только нехватку ресурсов, но и отказ. Минимум нужны автоматические копии файлов и базы, независимое хранилище, мониторинг, инструкция восстановления и регулярный тест копии. Частота зависит от того, сколько заказов бизнес готов потерять.
Если простой одного сервера неприемлем, одной ежедневной копии недостаточно: восстановление займёт время. Рассматривают репликацию базы, резервный узел, балансировку, дублирование критичных сервисов и управляемое переключение. При этом каждая дополнительная часть должна мониториться и тестироваться.
Отдельно проверяют платежи: повторный запрос после тайм-аута не должен создавать двойной заказ или списание. Внешние интеграции проектируют идемпотентно и сохраняют идентификаторы операций.
Как проверить хостинг до переноса магазина
Рекламные обещания не заменяют тест на копии проекта. В изолированную среду переносят обезличенную или защищённую копию каталога, прогревают кеш и запускают сценарии, похожие на реальную работу.
- одновременное открытие категорий и карточек;
- несколько комбинаций фильтра и поиска;
- добавление товара в корзину и оформление тестового заказа;
- фоновый обмен цен и остатков;
- создание резервной копии;
- кратковременный пик выше обычной нагрузки.
Во время теста измеряют не только среднее время ответа, но и 95-й процентиль, ошибки, очередь PHP-процессов, CPU, память, диск, блокировки базы и время внешних API. После этого становится понятно, ограничивает ли проект инфраструктура или код.
Четыре сценария выбора для бизнеса
| Сценарий | Главный риск | На чём сосредоточиться |
|---|---|---|
| Большой каталог, но умеренный трафик | Медленный фильтр и длительный импорт | База, индексы, пакетный обмен, кеш |
| Магазин с регулярными рекламными пиками | Исчерпание процессов и резкий рост TTFB | Запас CPU/RAM, page cache, CDN, масштабирование |
| Полный обмен с 1С несколько раз в день | Блокировки и неактуальные остатки | Очереди, дельта-обмен, расписание и мониторинг |
| B2B-магазин с персональными ценами | Ошибочное кеширование и тяжёлые расчёты | Разделение публичных и персональных данных, архитектура, SLA |
Для небольшого магазина с предсказуемой нагрузкой хорошая оптимизация и правильно настроенный VPS часто важнее сложного кластера. Для критичного B2B-проекта выбор начинается с аналитики бизнес-требований, RPO/RTO и схемы интеграций, а стоимость инфраструктуры появляется после архитектуры и теста.
Частые вопросы
Сколько оперативной памяти нужно интернет-магазину с большим каталогом?
По количеству товаров это определить нельзя. Нужно сложить потребности PHP, базы, кеша, поиска и фоновых задач, затем проверить пиковое потребление и оставить запас. Одинаковые каталоги на разных CMS могут требовать разный объём.
Подойдёт ли обычный виртуальный хостинг?
Для небольшого магазина с простой логикой — возможно. Если нужны собственные версии ПО, Redis, очереди, длительные импорты или гарантированные ресурсы, обычно переходят на VPS/VDS либо более сложную инфраструктуру.
Нужен ли отдельный сервер для базы данных?
Не обязательно. Он оправдан, когда базе тесно рядом с приложением, нужна репликация или независимое масштабирование. До этого стоит проверить запросы, индексы, кеш и настройки существующей СУБД.
Можно ли выбрать сервер только по числу товаров?
Нет. Важны предложения, свойства, фильтр, трафик, частота изменений, заказы, изображения и интеграции. Каталог из 300 тысяч редко меняющихся карточек может быть легче меньшего, но динамичного B2B-проекта.
Что важнее для каталога: быстрый процессор или NVMe?
Зависит от узкого места. PHP и расчёты могут упираться в CPU, а база и импорт — в задержки диска. Решение принимают по мониторингу и тесту, а не по одному параметру конфигурации.
Как перенести крупный магазин без потери заказов?
Подготовить новую среду, заранее синхронизировать файлы и основную базу, сократить TTL DNS, назначить окно финальной синхронизации, проверить платежи и интеграции, а после переключения сохранить возможность контролируемого отката.
Нужна конфигурация под реальную нагрузку магазина?
German Web может провести технический аудит магазина, проверить каталог, фильтр, базу и обмены, подготовить нагрузочный сценарий и предложить инфраструктуру без покупки лишних ресурсов. Работа разработчика рассчитывается по ставке 2 300 ₽ в час; итоговый объём определяем после диагностики проекта.
