Аудит нагрузки и Highload для 1С-Битрикс: найдём точку деградации до того, как её найдёт пик

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

Почему поведение под нагрузкой нелинейно

Главная ловушка в том, что сайт ведёт себя совсем по-разному на малом и большом числе пользователей. Пока ресурсов хватает с запасом, добавление новых посетителей почти не сказывается на времени ответа: страница как открывалась за полсекунды, так и открывается. Но у любого ресурса есть потолок — число ядер процессора, объём пула соединений к базе, размер кеша, пропускная способность диска. Как только нагрузка приближается к этому потолку, время ответа начинает расти уже не линейно, а лавинообразно: запросы выстраиваются в очередь, очередь растёт, ожидание увеличивает число одновременных запросов, и система входит в штопор. Это и есть точка деградации, и находится она часто гораздо ближе к обычному трафику, чем думает владелец проекта.

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

Чем мы воспроизводим пик

Для разных задач мы используем разные инструменты. k6 удобен для сценарных тестов и хорошо ложится на современные пайплайны: на нём мы описываем путь пользователя кодом и аккуратно наращиваем нагрузку ступенями. JMeter незаменим, когда нужно собрать сложный сценарий с ветвлениями, авторизацией и проверкой содержимого ответов. Yandex.Tank силён на резких всплесках: им мы моделируем волну трафика, которая приходит после рассылки или выхода рекламы, когда за первые минуты на сайт обрушивается большая часть аудитории. Часто эти инструменты дополняют друг друга в рамках одного аудита, и выбор зависит не от моды, а от того, какой профиль нагрузки нужно воспроизвести.

Мы не гоняем абстрактную нагрузку из учебника. Сначала собираем реальный профиль трафика вашего проекта: какие страницы самые посещаемые, как соотносятся просмотры каталога и оформления заказов, в какие часы случаются всплески, как ведёт себя аудитория после рассылки. На основе этого строим сценарии, близкие к жизни, потому что синтетический тест по нерелевантным страницам покажет красивые, но бесполезные цифры. Если предстоит конкретное событие — большая распродажа, телереклама, массовая рассылка, — мы отдельно моделируем именно его профиль. На этом этапе полезно опереться и на данные из обычного аудита производительности, чтобы понимать, как страницы ведут себя в спокойном режиме, и отделить медленный код от нехватки ресурсов под пиком.

Где обычно прячутся бутылочные горлышки

Под нагрузкой первым упирается не всегда то, на что грешат. Самый частый виновник — база данных: тяжёлые и неоптимальные запросы, которые незаметны на одном пользователе, под пиком начинают блокировать друг друга, исчерпывают пул соединений и вызывают дедлоки. На втором месте — кеш: если горячие страницы кешируются плохо или кеш инвалидируется слишком часто, каждый запрос идёт в полную генерацию, и процессор быстро упирается в потолок. Дальше идёт конфигурация веб-слоя: число воркеров PHP-FPM, настройки nginx, лимиты на соединения — неверные значения превращают мощный сервер в узкое горло.

Отдельная и недооценённая зона — фоновые процессы. Агенты Битрикса, обмен с 1С, отправка писем, пересчёт скидок и наполнение поисковых индексов конкурируют за те же процессор и базу, что и живые пользователи. В обычный день это незаметно, но на пике именно фоновая задача может добить систему, которая и так на грани. Поэтому в аудите мы всегда смотрим на очереди и фоновые агенты под нагрузкой и проверяем, разведены ли они с пользовательским трафиком. Здесь же оцениваем, какие тяжёлые данные стоит вынести в highload-блоки, а какие очереди — перенести в полноценный брокер сообщений, чтобы рассылки и обмен не конкурировали с заказами.

Что значит точка деградации простыми словами

Точка деградации — это уровень нагрузки, после которого сайт перестаёт справляться: время ответа резко растёт, появляются ошибки, часть запросов отваливается. Мы выражаем её в понятных величинах — числе запросов в секунду и числе одновременных пользователей. Зная этот порог, владелец проекта впервые получает честный ответ на вопрос «сколько мы выдержим», и может соотнести его с ожидаемым трафиком акции. Если порог выше ожидаемого пика — есть запас. Если ниже — это сигнал действовать заранее, а не во время распродажи.

Что вы получаете на выходе аудита

Результат аудита — это карта бутылочных горлышек и план повышения отказоустойчивости, а не папка с графиками. По каждому узкому месту мы показываем, сколько запаса по нагрузке оно отнимает и насколько сдвинется точка деградации после его устранения. Это позволяет расставить приоритеты по деньгам: сначала делается то, что поднимает потолок сильнее всего при наименьших усилиях. План мы делим на быстрые меры — настройка кеша, конфигурация PHP-FPM и nginx, индексы в базе, разведение фоновых задач, — которые часто поднимают потолок за часы, и стратегические — масштабирование, балансировка нагрузки, вынос данных в highload-блоки, перенос очередей в брокер, кеширование на edge. Если узким местом оказывается сама архитектура решения, мы передаём выводы в работу по highload-разработке на Битрикс, чтобы изменения вносились системно, а не латали симптомы.

Отдельно мы всегда оговариваем, чего делать не нужно. Соблазн при первой же тревоге докупить сервер мощнее велик, но без аудита это часто выброшенные деньги: если упирается медленный запрос или плохой кеш, более мощное железо лишь немного отодвинет ту же стену. Наша задача — показать, где реальный потолок, и помочь вложиться в правильное место, а не в самое дорогое.

Стресс-тест и тест на выносливость

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

Что именно показывают метрики прогона

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

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

Когда заказывать аудит, чтобы он был не зря

Лучший момент — заранее, до запланированного события. Если впереди распродажа, телереклама, крупная рассылка или сезонный всплеск, аудит стоит провести за две-три недели, чтобы осталось время внедрить меры и прогнать проект повторно. Второй разумный повод — после заметного роста проекта: расширился каталог, добавились интеграции и личные кабинеты, выросло число заказов. То, что год назад работало с запасом, могло незаметно подобраться к потолку. Третий повод — если проект уже падал или тормозил на пике: тогда аудит не предположение, а разбор уже случившегося, чтобы это не повторилось.

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

Как мы подтверждаем результат

Аудит не заканчивается отчётом. После того как вы внедрите меры — сами или с нашей помощью, — мы прогоняем нагрузочный тест повторно по тем же сценариям и показываем, насколько сдвинулась точка деградации и вырос запас по RPS. Это превращает работу из обещаний в проверяемый результат: было сорок запросов в секунду до отказа, стало двести; падало на трёхстах одновременных пользователях, держит тысячу. Такой замер до и после — лучшее доказательство, что деньги вложены в дело, а сайт действительно готов к пику.

С чего начать

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