Холодный старт WebAssembly: что показывают тесты

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

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

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

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

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

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

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

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

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

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

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

Aurabase запускает свои функции Edge на Wasmtime в производстве, а не в пилотном проекте. Вот именно то, что позволяет заявка, и где эта претензия заканчивается.

Зависимость объявляется жесткой с активированными функциями async и cranelift в производственных зависимостях службы, а не в dev-dependency или комментарии:

# Актуальная выписка из репозитория
[dependencies]

# Среда выполнения WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Чего не сказано в этом файле: на сегодняшний день в репозитории для этой среды выполнения не существует показателей холодного запуска, измеренных в соответствии с протоколом, описанным в нашей методологии тестирования . До тех пор, пока не будут опубликованы датированные измерения с детализированными процентилями, аппаратным обеспечением и рабочей нагрузкой, никакие показатели Aurabase не могут быть указаны в качестве измеряемой характеристики продукта. Общую архитектуру платформы см. в нашей основной статье Архитектура Aurabase Rust. Конкретное сравнение WASM с холодным запуском и контейнера с холодным запуском, независимо от рассматриваемого здесь методологического вопроса, см. в нашей специальной статье WASM против контейнеров.

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

1. Какие этапы включены? Загрузка сети, проверка, компиляция, создание экземпляра, первый вызов: цифра, которая считает только часть, не сравнима с цифрой, которая считает их все.
2. Действительно ли модуль был «холодным»? Модуль, уже находящийся в памяти или в дисковом кеше, не тестирует то же самое, что модуль, загружаемый впервые.
3. JIT-компиляция или предварительно скомпилированный артефакт (AOT)? Эти две стратегии имеют структурно разные стартовые затраты.
4. Одна цифра или распределение? Лучший результат из десяти не имеет такого же значения, как p95 из тысячи.
5. Указано оборудование и регион? Рисунок без спецификации оборудования не может быть воспроизведен третьей стороной.
6. Сравнение при равной нагрузке и топологии? Сравнение локальной среды выполнения с управляемой службой без отчета об этом искажает показания.
7. Дата и версия проверенной среды выполнения? Недатированная цифра для проекта, который быстро развивается, через несколько месяцев ничего не значит.