Производительность браузера: оптимизация в масштабе

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

Кратко

• Измерьте типовые задачи при холодном старте и прогретой работе, прежде чем задавать лимит воркеров.
• Найдите ограниченный ресурс и задайте явные правила допуска и восстановления для ограниченной очереди.
• Меняйте только одну затрату за раз и принимайте решение об откате по той же нагрузке и цели сервиса.

Содержание

• Сначала измерьте нагрузку
• Защитите бюджет обратным давлением
• Настраивайте по одной статье затрат
• Принимайте выпуски по данным о восстановлении
• Где BotBrowser полезен
• Заключение

Сначала измерьте нагрузку

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

Мощность в продакшене зависит от страниц, режима браузера, длительности сеанса, сетевого маршрута, выпуска, графического бэкенда, пакета профиля, хоста и параллелизма, который использует приложение. Измеряйте эти параметры вместе, прежде чем менять настройки памяти, CPU, сети или жизненного цикла. Цель в том, чтобы задачи стабильно завершались при согласованной защите приватности, а не в том, чтобы запустить как можно больше воркеров.

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

Создайте эталон мощности

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

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

Измеряйте холодный старт и прогретый запуск отдельно. Холодный результат отражает замену хоста и восстановление после развертывания. Прогретый результат отражает устойчивую работу сервиса. Важны оба, но объединение их в одно число затрудняет сравнение выпусков.

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

Задайте бюджет ресурсов

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

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

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

Сопоставьте симптом с показателем, который его объясняет

Симптом говорит, куда смотреть, а не что менять. Таблица связывает типичное наблюдение с показателем, который дает ответ, чтобы разбор мощности начинался с измерений, а не с догадки о хосте.

Симптом	Какой показатель читать	Решение
Ожидание в очереди растет, CPU ровный	p95_queue_wait против completion_latency	Предел задает политика допуска; добавляйте слоты по классам после снижения ожидания
Память растет, CPU низкий	rss_per_context по открытым контекстам	Закрывайте простаивающие контексты или снижайте вес страницы; хост ограничен памятью
CPU близок к потолку хоста	cpu_saturation вместе с error_rate_after_retry	Снизьте параллелизм или переведите короткие сеансы на урезанную сборку
p95 времени страницы растет при ровной пропускной способности	p95_page_time по маршруту вместе с error_rate_after_retry	Одна медленная зависимость или маршрут; найдите URL до добавления хостов
error_rate_after_retry растет вместе с queue_depth	Повторы на завершенную задачу	Обратное давление возвращает мощность до окончания очистки; отложите повтор

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

Проводите разбор инцидента в фиксированном порядке

Запишите порядок как политику, чтобы два оператора приходили к одному ответу:

1. Заморозьте новый допуск, чтобы выборка перестала меняться во время чтения.
2. Сравните rss_per_context при сбойном параллелизме с тем же значением при последнем принятом параллелизме. Ровное значение при свободной памяти хоста ниже четверти номинала указывает на хост.
3. Сравните p95_queue_wait с completion_latency. Ожидание в очереди выше задержки завершения при CPU ниже половины номинала указывает на политику допуска.
4. Сравните launch_duration на двух уровнях параллелизма. Запуск, который растет с числом параллельных чтений профилей, указывает на хранилище профилей.

Этот порядок исключает проблему хоста только тогда, когда шаги 2 и 4 ровные, а шаг 3 показывает ожидание внутри очереди. Меняйте первой ту строку, что пересекла линию политики; правка двух строк сразу оставляет инцидент без владельца. Четверть и половину считайте рабочей политикой этого развертывания, а не универсальным фактом о браузерах.

Защитите бюджет обратным давлением

Поставьте ограниченную очередь перед работой браузера. Допускайте новую задачу только тогда, когда у развертывания есть мощность для ее класса нагрузки. Когда очередь достигает предела, отклоняйте, откладывайте или перенаправляйте работу по политике сервиса. Не позволяйте вызывающим сторонам напрямую создавать неограниченную браузерную работу.

Используйте отдельные очереди, если у нагрузок заметно разная стоимость или разные цели обслуживания. Длинная задача с медиа не должна занимать все слоты, нужные коротким проверкам приложения. Справедливое планирование и лимиты по классам делают сервис проще в эксплуатации, чем одно глобальное число параллелизма.

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

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

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

Нагрузка, которая проходит на 20 контекстах и падает на 40

Тот же хост, те же страницы и то же семейство профилей могут пройти разбор мощности на 20 контекстах и не пройти на 40. У сбоя три частые причины, и каждая оставляет свой показатель.

• Память хоста. rss_per_context остается ровным, но суммарная резидентная память выходит за свободную память хоста, ядро начинает вытеснять страницы, и самые медленные контексты зависают. Решение: меньше контекстов на хост или более крупный хост.
• Время загрузки профиля. launch_duration растет с параллелизмом, потому что каждый контекст читает свой профиль при запуске. Локальное хранилище и меньший набор профилей сокращают путь запуска; сам хост не является пределом.
• Политика допуска. p95_queue_wait растет, хотя CPU далеко ниже потолка и память стабильна. Очередь допускает работу быстрее, чем очистка возвращает мощность, поэтому разделите классы или отложите повтор.

Выполните случай с 40 контекстами один раз, заморозив допуск после первого зависания. Если rss_per_context и launch_duration совпадают с прогоном на 20 контекстах, хост не виноват и исправление в очереди. Если они расходятся, сначала исправьте ресурс и лишь затем политику допуска, потому что смена политики не вернет уже потерянную память.

Запишите выбранную причину, два уровня параллелизма, а также rss_per_context, launch_duration и p95_queue_wait в запись решения о мощности для этой нагрузки, чтобы следующий разбор начинался с этого сравнения, а не с пустой страницы.

Настраивайте по одной статье затрат

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

Память и жизненный цикл страниц

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

Закрывайте страницы сразу, чтобы браузер освободил ресурсы завершенной работы. Вызов page.close() задает браузеру четкую границу жизненного цикла, тогда как переход на другой URL не прекращает владение страницей. Закрывайте и сам браузер на каждом пути выхода и используйте супервизор развертывания, чтобы выявлять не отвечающий воркер.

const page = await context.newPage();
try {
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  // Здесь читайте данные, которые нужны сценарию.
} finally {
  await page.close();
}

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

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

Записывайте в журналы приложения завершение запуска, статус выхода, stderr, длительность задач, задержку в очереди и закрытие контекстов, а память хоста отслеживайте стандартными средствами операционной системы. Задавайте оповещения по измеренной мощности хоста и цели сервиса и следите за трендами, а не ждите исчерпания ресурсов.

CPU и частота видео

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

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

Снижайте частоту видео, когда полное визуальное воспроизведение не нужно. Страницы с большим количеством видео могут держать декодирование и отрисовку активными, даже если автоматизации нужны лишь редкие визуальные обновления. Для профилей с включенным Video FPS Control параметр --bot-video-fps задает фактическую частоту видео отдельно от FPS медиа, который видят страницы.

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-video-fps=1:30 \
  --headless

Применяйте это для мониторинга с большим количеством видео, проверки качества или долгоживущих страниц, где покадровые пиксели видео не входят в результат. Синтаксис описан в Video FPS Control, а проверенная нагрузка в бенчмарке. Снижение CPU в бенчмарке дает ориентировочные диапазоны для одной проверенной видеонагрузки, а не обязательства по мощности и не пороги прохождения.

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

Проверяйте и тип результата, важный для сценария. Извлечение DOM, перехват API, снимки экрана и проверки пикселей медиа по-разному переносят сниженную визуальную частоту, а пиксельный вывод следует фактической частоте. Держите параметр рядом с профилем запуска или описанием задачи, чтобы следующий оператор видел, какие задачи используют сниженную частоту медиа, и отделяйте его от параметров FPS дисплея.

Сеть и хранилище

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

Когда пропускная способность маршрута ограничена, выборочная маршрутизация может оставлять выбранные пути запросов вне прокси. Синтаксис правил и требуемая лицензия описаны в Proxy Selective Routing. Подходящие запросы соединяются напрямую, поэтому решите, какие ресурсы могут идти мимо маршрута прокси по утвержденной сетевой политике, и повторяйте проверку маршрута при каждой смене учетных данных, региона или выхода.

Прокси добавляет сетевую задержку каждому запросу, который через него проходит. Держите маршрут стабильным во время бенчмарка и сравнивайте p95 request latency до смены региона выхода.

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

Графика и headless-хосты

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

Headless-режим может сократить часть работы оконной системы, но страница по-прежнему использует визуальные, сетевые, JavaScript- и дисковые ресурсы, поэтому считайте разницу зависящей от нагрузки. Оставляйте графическую поддержку включенной, потому что ее отключение может изменить возможности отрисовки для нагрузок, использующих WebGL или WebGPU.

Используйте руководство Linux GPU Backend, когда развертывание работает без физического дисплея. В Linux сохраняйте один и тот же выбранный графический бэкенд на сопоставимых воркерах. Изменение, убирающее нужную возможность браузера, не является допустимым улучшением производительности.

Принимайте выпуски по данным о восстановлении

Сравнивайте представительные этапы работы

Кандидата в выпуск нужно измерять относительно утвержденного эталона на тех же классах нагрузки и том же образе хоста. Держите холодный старт, прогретую устойчивую работу и контролируемое завершение отдельными этапами. Холодный старт показывает, могут ли новые воркеры предсказуемо входить в работу. Устойчивый этап показывает, остаются ли задержка в очереди и расход ресурсов стабильными после прогрева кэшей и соединений. Завершение показывает, возвращается ли мощность после завершенной, отмененной и неудачной работы. Сравнивайте p95 queue delay с задержкой завершения, чтобы замечать растущее ожидание допуска.

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

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

Применяйте явные критерии приемки

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

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

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

Проверяйте обратное давление и восстановление

Приемочное тестирование должно включать период, когда поступление задач превышает доступную мощность обслуживания. Убедитесь, что ограниченная очередь применяет предусмотренную политику допуска, защищает уже выполняющуюся работу и возвращается в обычный диапазон после спада спроса. Проверьте, откладываются ли повторы по политике, а не сразу добавляют нагрузку.

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

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

Сохраняйте данные для отката

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

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

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

Где BotBrowser полезен

Для сеансов с большим количеством видео BotBrowser поддерживает --bot-video-fps (ENT Tier2, на профилях с включенным Video FPS Control), который снижает фактическую частоту декодирования и отрисовки видео, а сообщаемый FPS медиа задается отдельно. Когда полная визуальная частота кадров не нужна, это может снизить нагрузку на CPU, поэтому его стоит проверить как одно контролируемое изменение в описанном плане. BotBrowser не может гарантировать экономию CPU или значение мощности для каждой нагрузки, не заменяет эталоны мощности, очереди, обратное давление и корректное закрытие, за которые отвечает оператор, и не может сохранить покадровый пиксельный вывод после снижения фактической частоты. Повышайте фактическое значение, когда сценарий измеряет пиксели видео.

Для развертываний, оценивающих сценарии с отдельными контекстами, Per-Context Fingerprint (ENT Tier3) является зависящей от лицензии возможностью, которую стоит измерить на той же разрешенной нагрузке и при тех же требованиях к приватности, что и существующая топология. Считайте результат данными для конкретной нагрузки, а не общим обязательством по мощности. BotBrowser не задает мощность хоста, политику очередей, производительность прокси и поведение страниц, поэтому эти решения остаются за владельцем приложения.

Скачайте BotBrowser для подготовки развертывания или свяжитесь с нашей корпоративной командой для планирования инфраструктуры. Детали реализации приведены в материалах Настройка headless-сервера, Руководство по развертыванию в Docker, CLI Recipes и Лучшие практики для снимков экрана.

Когда странице нужны подсказки очереди в дополнение к ёмкости хоста, приоритеты scheduler.postTask дают запись отмены и запасного пути, сохраняющую эту границу явной.

Источники

• BotBrowser FPS Control
• Бенчмарк BotBrowser
• BotBrowser Proxy Selective Routing
• BotBrowser Linux GPU Backend
• Playwright Page API

Заключение

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