Pingveraблог ← Блог
Главная › Блог › Нагрузочное тестирование сайта интернет-магазина перед «Чёрной пятницей»

Нагрузочное тестирование сайта интернет-магазина перед «Чёрной пятницей»

16 октября 2026 · 11 мин чтения

Нагрузочное тестирование сайта интернет-магазина перед «Чёрной пятницей»

Нагрузочное тестирование сайта показывает, при каком потоке посетителей магазин начинает отвечать медленно или с ошибками. Перед «Чёрной пятницей» его стоит провести за 4–6 недель до старта акции. Тогда останется время найти узкое место, исправить его и проверить исправление повторным тестом.

Минимальный рабочий вариант делается за один день. Посчитайте пиковую нагрузку по прошлой распродаже, напишите сценарий из 4–5 страниц (главная, каталог, карточка, поиск), запустите его бесплатным инструментом k6 на копии сайта или в ночное окно на рабочем сайте. Остановите тест, как только доля ошибок или время ответа выйдут за порог. Результат теста: число, при котором магазин ещё держится, и список того, что ломается первым.

Коротко

Почему этим стоит заняться сейчас

По данным обзора Hi-Tech Mail, «Чёрная пятница» в 2026 году выпадает на 27 ноября: дату считают от американского Дня благодарения, это четвёртый четверг ноября (26 ноября 2026 года). Акция в магазинах обычно длится все выходные, до 29 ноября. За две недели до неё, 11 ноября, проходит распродажа 11.11, которую поддерживают маркетплейсы.

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

Нагрузочный тест требует времени не на запуск, а на исправления. Переезд на другой тариф хостинга, настройка кеша в 1С-Битрикс, замена тяжёлого плагина WooCommerce или оптимизация запросов к базе занимают дни. Поэтому середина октября — последний спокойный момент. Ближе к акции действует заморозка изменений, о которой мы писали в плане подготовки магазина к распродаже.

Какие бывают виды нагрузочного тестирования

В документации Grafana k6 описаны шесть типов тестов. Для магазина перед распродажей хватает трёх, остальные полезно знать по названию.

Вид теста Что проверяет Длительность по документации k6 Нужен перед акцией
Дымовой (smoke) Сценарий работает, сайт отвечает при минимальной нагрузке Секунды или минуты Да, перед каждым прогоном
Под средней нагрузкой (average-load) Как сайт ведёт себя при ожидаемом трафике 5–60 минут Да
Стресс (stress) Поведение выше ожидаемой нагрузки 5–60 минут Желательно
Всплеск (spike) Выдержит ли сайт резкий наплыв за минуты Несколько минут Да: старт акции и рассылки дают именно всплеск
Длительный (soak) Стабильность за много часов: утечки памяти, переполнение диска Часы Если акция длится несколько дней
До отказа (breakpoint) Где предел системы По необходимости Редко, обычно не на рабочем сайте

В документации k6 отдельно сказано, что ни один тип теста не снимает все риски. Набор прогонов выбирают под то, что может сломаться именно у вас.

Пошаговая процедура на один день

1. Посчитайте целевую нагрузку. Откройте Яндекс Метрику за период прошлой распродажи и найдите самый нагруженный час по просмотрам страниц. Разделите просмотры за час на 3600: это средние просмотры в секунду в пиковый час. Умножьте на ожидаемый рост трафика (по плану рекламы и рассылок) и на запас под всплеск в первые минуты акции. Запас выберите сами по прошлому опыту: если рассылка уходит на всю базу в 00:00, всплеск будет резче, чем при плавном старте рекламы. Одна страница порождает много запросов к картинкам и скриптам, но если статика отдаётся через CDN, нагрузку на сервер создают в основном HTML-страницы и AJAX-запросы.

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

3. Решите, где тестировать. Лучший вариант: копия сайта на таком же сервере, как рабочий. Если копии нет, тестируйте рабочий сайт ночью, при минимальном трафике, с жёсткими порогами остановки. Предупредите хостинг заранее: массовые запросы с одного адреса похожи на атаку, и защита от DDoS может заблокировать IP или весь сайт.

4. Отключите внешние сервисы. Сценарий не должен создавать заказы, проводить оплаты, рассылать письма и SMS, запрашивать расчёт доставки у служб. Для таких шагов используйте тестовый режим платёжного сервиса или отдельный стенд. Трафик теста исключите из Метрики фильтром по IP, иначе отчёты за этот день станут бесполезны.

5. Установите k6 и запустите дымовой прогон. На Ubuntu и Debian k6 ставится из репозитория dl.k6.io, на macOS командой brew install k6, на Windows через winget install k6 --source winget, есть и Docker-образ grafana/k6. Дымовой прогон с одним-двумя пользователями проверяет, что сценарий не упирается в 404 и редиректы.

6. Прогон под ожидаемой нагрузкой, затем всплеск. Нагрузку поднимайте ступенями. Во время теста смотрите не только отчёт k6, но и сервер: загрузку процессора, память, число соединений к базе, медленные запросы. В 1С-Битрикс для поиска узких мест есть модуль «Монитор производительности» с панелью производительности. В WordPress ту же роль играют журнал медленных запросов MySQL и мониторинг сервера.

7. Зафиксируйте результат и исправьте первое узкое место. Запишите, при какой нагрузке выросли ошибки или время ответа, что упёрлось первым (процессор, база, PHP-воркеры, внешний модуль), и повторите тест после исправления.

Сценарий k6, который можно взять за основу

Сценарий только читает страницы и ничего не меняет в магазине. Замените адреса на свои. Нагрузка задана в итерациях в минуту: исполнитель ramping-arrival-rate запускает новые итерации независимо от того, как быстро отвечает сайт. Так ведут себя реальные покупатели: они приходят по рассылке, даже если сайт уже тормозит.

// shop-load.js — запуск: k6 run shop-load.js
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = 'https://staging.example-shop.ru'; // копия сайта или рабочий сайт ночью

const PAGES = [
  '/',                                  // главная
  '/catalog/kurtki/?size=48',           // каталог с фильтром
  '/product/kurtka-zimnyaya-123/',      // популярная карточка
  '/search/?q=пуховик',                 // поиск
];

export const options = {
  discardResponseBodies: false,
  scenarios: {
    sale_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 60,          // итераций в минуту на старте
      timeUnit: '1m',
      preAllocatedVUs: 50,
      maxVUs: 300,
      stages: [
        { target: 300, duration: '5m' },   // выход на ожидаемую нагрузку
        { target: 300, duration: '10m' },  // держим
        { target: 900, duration: '2m' },   // всплеск: старт акции или рассылка
        { target: 900, duration: '3m' },
        { target: 0, duration: '2m' },     // спад
      ],
    },
  },
  thresholds: {
    // остановить тест, если ошибок больше 2%
    http_req_failed: [{ threshold: 'rate<0.02', abortOnFail: true, delayAbortEval: '30s' }],
    // 95% ответов быстрее 2 секунд
    http_req_duration: [{ threshold: 'p(95)<2000', abortOnFail: true, delayAbortEval: '30s' }],
    checks: ['rate>0.98'],
  },
};

export default function () {
  for (const path of PAGES) {
    const res = http.get(`${BASE}${path}`, { tags: { page: path } });
    check(res, {
      'статус 200': (r) => r.status === 200,
      'страница не пустая': (r) => r.body && r.body.length > 5000,
      'нет текста ошибки': (r) => r.body && !r.body.includes('Service Unavailable'),
    });
    sleep(Math.random() * 3 + 1); // пауза покупателя между страницами
  }
}

На что обратить внимание в этом файле:

Цифры в stages и порогах здесь условные. Подставьте свои из шага 1.

Таблица: что проверять и кто отвечает

Риск Ответственный Как проверить Когда
Каталог с фильтрами тормозит под нагрузкой Разработчик или студия на поддержке Время ответа страницы каталога в отчёте k6 по тегу page Каждый прогон
Кончаются PHP-воркеры или соединения к базе Администратор сервера, хостинг Метрики сервера во время теста, журнал ошибок Каждый прогон
Кеш сбрасывается при обновлении цен и остатков из 1С Разработчик, ответственный за обмен Запустить тест во время обмена с 1С Один раз до акции
Защита хостинга блокирует наплыв покупателей Владелец, хостинг Письменно уточнить лимиты и правила защиты До первого теста
Внешний модуль (доставка, отзывы, чат) замедляет страницу Разработчик Сравнить время ответа с модулем и без Один раз до акции
Сайт держит трафик, но заказы не создаются Владелец, e-commerce-менеджер Тестовый заказ после каждого прогона, контроль потока заказов После теста и в день акции

Пример разбора: магазин на 1С-Битрикс

Это условный пример, цифры придуманы для иллюстрации.

Магазин одежды на 1С-Битрикс в прошлую «Чёрную пятницу» получил в пиковый час 36 000 просмотров страниц, то есть в среднем 10 в секунду. В этом году реклама вдвое больше, плюс рассылка на всю базу ровно в полночь. Команда закладывает 20 просмотров в секунду как ожидаемую нагрузку и 60 на всплеск в первые минуты.

Первый прогон на копии сайта: главная и карточка держат нагрузку спокойно, они закешированы. Каталог с фильтром по размеру начинает отвечать дольше 2 секунд уже на 25 просмотрах в секунду, на 40 появляются ошибки 502. На панели производительности и в журнале медленных запросов видно, что каждая комбинация фильтров строит выборку заново. Разработчик включает кеширование компонента каталога и фасетный индекс для свойств товаров, повторный тест проходит до 60 просмотров в секунду без нарушения порогов.

Второе открытие: при запуске теста во время обмена с 1С кеш каталога сбрасывается, и время ответа снова растёт. Решение: на дни акции перенести полную выгрузку на ночь, а днём передавать только остатки.

Частые ошибки

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

Вопросы и ответы

Можно ли сделать нагрузочное тестирование сайта онлайн, без установки программ?

Да, есть облачные сервисы, включая облачную версию k6 от Grafana. Они удобны, когда нужно дать нагрузку из нескольких регионов. Но расчёт нагрузки, выбор страниц и пороги остаются вашей работой, и правила про внешние сервисы и предупреждение хостинга действуют так же.

Сколько стоит такое тестирование?

k6 бесплатен и запускается на любом сервере. Основные затраты: время разработчика на сценарий и разбор результатов и, если нужно, временный сервер для запуска теста. Исправления узких мест считаются отдельно.

Если тест прошёл, можно больше ни о чём не думать в день акции?

Нет. Тест проверяет, что сайт отвечает. В день акции магазин может быть доступен и при этом не продавать: отвалилась оплата, обмен с 1С не обновил цены, письма с подтверждением не уходят. Об этом подробнее в статье «Магазин работает, а заказов нет».

Как не пропустить проблему в сам день акции

Нагрузочный тест отвечает на вопрос «выдержим ли». В день распродажи нужен второй контроль: доступность ключевых страниц раз в минуту из нескольких регионов и поток заказов в сравнении с обычным часом. В Pingvera это делается без доступа к серверу: проверки доступности и SSL идут каждую минуту даже на бесплатном тарифе (до 5 сайтов), а для WooCommerce детектор аномалий на тарифе Business сравнивает поток заказов с почасовой нормой и предупреждает, если сайт отвечает, а заказов нет.

Источники

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

Читайте также: Минимальная цена в акциях маркетплейса перед 11.11 · Проверка лендинга перед запуском рекламы · Статус-страница, которую читают не только люди · Метка «опасный сайт» в браузере: что делать · Бесплатно проверить сайт.

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал