Планирование ёмкости BrowserContext

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

BrowserContext разделяет хранилище и состояние сессии в общей браузерной инфраструктуре. Это не граница операционной системы, процесса или безопасности. Если такие границы необходимы, используйте отдельный браузер или хост.

BotBrowser поддерживает Per-Context Fingerprint уровня ENT Tier 3: эта функция назначает отдельные профили нескольким BrowserContext в одном процессе браузера (изоляция контекстов и опубликованные тесты). Эти тесты описывают конкретные проверенные конфигурации. BotBrowser не гарантирует ёмкость на другом хосте, для другой нагрузки, профиля или жизненного цикла и не определяет универсальное безопасное число контекстов. Перед установкой ограничений допуска измерьте всю группу.

Кратко

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

Содержание

• Определите единицу выпуска и нагрузку
• Измерьте кривую ёмкости всей группы
• Задайте обратимые границы допуска и очереди
• Эксплуатируйте, восстанавливайте и откатывайте
• Записывайте решение, передавайте его и проверяйте повторно
• Заключение

Определите единицу выпуска и нагрузку

Подготовьте воспроизводимую нагрузку

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

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

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

Записывайте workloadRevision и activeContextCount для каждого запуска, чтобы сравнивать кандидатный и принятый выпуски в одинаковых условиях.

Классифицируйте нагрузку до подсчёта контекстов

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

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

Сравните холодный запуск и прогретое состояние

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

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

Запишите условия хоста и контейнера

Один и тот же браузер и профиль могут вести себя по-разному на более крупном хосте, в меньшем контейнере или на хосте с другой графической политикой. Запишите рядом с числом контекстов класс хоста, ограничения контейнера, маршрутизацию, хранилище, расширения и режим отображения. Так проверяющий сможет решить, применима ли прежняя запись о ёмкости. О том, как выбор сборки связан с ресурсами хоста на Linux x64, читайте в материале BotBrowser Trimmed для коротких сессий Linux x64.

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

Измерьте кривую ёмкости всей группы

Измерьте всю группу браузеров

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

Полезный результат представляет собой не универсальное число, а кривую ёмкости для конкретного выпуска и нагрузки:

• Исходное потребление памяти до создания первого контекста.
• Дополнительная память при активных контекстах.
• Задержка создания по мере роста параллельной работы.
• Восстановление после закрытия контекста.
• Запас хоста после очистки.

Читайте кривую памяти

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

В измерительной записи используйте поля activeContextCount, groupMemory, creationLatency и closeLatency, чтобы сравнивать одну и ту же кривую между выпусками.

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

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

Выберите полезные точки измерения

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

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

Учтите накладные расходы браузера и хоста

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

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

Сравните лёгкие и характерные страницы

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

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

Выполните приёмочные проверки

Выполните эти проверки с результатом «пройдено» или «не пройдено» в своей среде и сохраните записанный результат каждой. Принимайте ёмкость, только когда пройдены проверки 1, 2 и с 4 по 7.

1. Базовая линия: при нуле открытых контекстов запишите память и CPU хоста и память группы браузеров. Проверка пройдена, если базовая линия записана и воспроизводится от замера к замеру.
2. Ступенчатый тест: увеличивайте число активных контекстов минимум тремя ступенями. Выдерживайте каждую ступень при стабильной работе и в период простоя, а затем записывайте activeContextCount, groupMemory, creationLatency и число ошибок. Проверка пройдена, если ступень укладывается в ваш собственный бюджет задержки и ошибок и у хоста остаётся запас.
3. Принятая ёмкость: запишите её как самую высокую ступень, на которой проходит проверка 2, и установите предел допуска на этом значении или ниже.
4. Восстановление после закрытия: открывайте и закрывайте контексты N циклов, где N достаточно велико, чтобы проявился тренд. Проверка пройдена, если память стабилизируется около базовой линии и не растёт монотонно от цикла к циклу. Закрытие не обязательно возвращает всю память, поэтому объясняйте остаточную разницу, а не считайте её безвредной.
5. Запрос в очереди: заполните группу до предела и отправьте ещё один запрос. Проверка пройдена, если он допущен в заявленное время ожидания либо отклонён или отложен с понятным сигналом, который доходит до владельца группы.
6. Пауза и возобновление: выведите группу за порог приостановки. Проверка пройдена, если допуск приостанавливается и возобновляется только после восстановления запаса.
7. Повторный прогон: повторите проверки с 1 по 6 после обновления браузера, обновления профиля, смены хоста или контейнера, правки страницы или изменения жизненного цикла.

Задайте обратимые границы допуска и очереди

Установите бюджет с запасом

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

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

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

Наблюдайте за очередью

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

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

Сделайте допуск обратимым

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

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

Разделяйте группы только при необходимости

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

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

Эксплуатируйте, восстанавливайте и откатывайте

Учитывайте этапы жизненного цикла

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

Помечайте каждое наблюдение как lifecyclePhase (создание, активная работа, простой или закрытие), а после освобождения группы записывайте recoveryResult.

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

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

Эксплуатируйте долго работающую группу

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

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

Проверяйте решения о закрытии и повторном использовании

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

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

Записывайте решение, передавайте его и проверяйте повторно

Сравнивайте изменения браузера и профиля

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

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

Публикуйте только полезную часть

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

Шаблон записи о ёмкости

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

Поле	Что записать
workloadRevision	Редакцию сценария, неизменную для сравнения
activeContextCount	Одновременно активные контексты на каждом шаге
groupMemory	Память всей группы браузеров в каждой точке
creationLatency	Задержку создания контекста на каждом шаге
closeLatency	Задержку закрытия и последующее восстановление
lifecyclePhase	Создание, активную работу, простой или закрытие
queueAge	Возраст самого старого запроса в очереди в момент решения
recoveryResult	Вернулась ли группа в принятый рабочий диапазон

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

Привязывайте рекомендацию к версии

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

В руководстве Scaling BrowserContexts описаны изоляция контекстов и общие компромиссы по ресурсам. Здесь рассматриваются измеренные кривые памяти, длительные наблюдения, допуск и восстановление. В Browser Release Validation описан более широкий процесс продвижения кандидатной версии.

Подготовьте практическую передачу данных о ёмкости

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

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

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

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

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

Публичные источники

• Оптимизация производительности BotBrowser: Рекомендации по памяти группы и настройке запуска
• Изоляция контекстов BotBrowser: Профили по контекстам в одном процессе браузера
• Методика тестирования BotBrowser: Проверенное оборудование, сборка, метод и результаты по масштабу и жизненному циклу для Per-Context
• BrowserContexts в Playwright: Изоляция хранилища, сессий и cookie в BrowserContext

Заключение

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