WASM-модули Perfscale теперь можно «выжигать» прямо в бинарник: по внутренним замерам проекта, просадка скорости падает примерно с 9-12% до 1-3% относительно нативного вызова. Для команд, которые гоняют нагрузочные тесты и считают девятки доступности не декоративной метрикой, это важная деталь: расширяемость становится заметно дешевле по производительности.
Об изменениях в выпуске Perfscale news #13 сообщает Habr / Новости. В релизе команда рассказала о доработках Perfscale OSS и платформы, поддержке HTTP/3 на perfscale.ru, Helm chart для open source-версии и первом postmortem после инцидента с логином на .ru-домене.
Главное обновление связано с внешними библиотеками для Perfscale. Ранее проект добавил возможность писать собственные модули, выпустил SDK на Rust и TypeScript, а SDK для Go пока находится в работе. Проблема была ожидаемой: WASM дает удобный способ расширять систему, но вызов внешнего модуля обычно дороже, чем хардкод внутри приложения. Для нагрузочного тестирования это не академическая мелочь, а вполне практический вопрос: лишние проценты накладных расходов могут исказить картину, особенно если сценарии интенсивно используют пользовательские функции.
Новый механизм в Perfscale называется burn. WASM-модуль компилируется и встраивается в готовый бинарный файл Perfscale. Бинарник из-за этого становится тяжелее, зато код выполняется ближе к нативному варианту. Есть и обратная операция — deburn: внешний модуль можно отсоединить от бинарника. По приведенным в источнике замерам на примере random нативный вызов принят за 1, WASM без burn на холодном запуске показывает 1,11 ± 0,01, на горячем — 1,09 ± 0,01, а WASM с burn — 1,01 ± 0,01. В человеческом переводе: без встраивания потери находятся примерно в районе 9-12%, после встраивания — около 1-3%.
В OSS-версии это выглядит как техническая оптимизация для тех, кто хочет расширять Perfscale своими библиотеками и при этом не платить слишком большую цену за абстракцию. Заодно команда упомянула Helm chart для Perfscale OSS, исправления formatter в CI, закрытие dependabot-алертов и работу с CVE. Набор не эффектный для пресс-релиза, зато понятный любому, кто хотя бы раз пытался поддерживать инструмент, которым пользуются не только авторы.
В платформенной версии burn автоматизировали на уровне машины. Пользователь добавляет WASM-модуль, после чего бинарник на машине обновляется автоматически. Управлять выжиганием можно и через API. В интерфейсе machines → machine details уже предустановлен std/random, удалить его нельзя, а внешние библиотеки можно убирать. Для команд это снижает ручную возню: не нужно каждый раз отдельно собирать и раскладывать бинарники, чтобы получить ускорение пользовательских модулей.
Еще одно изменение — поддержка HTTP/3 на perfscale.ru. Команда отдельно уточняет, что Cloudflare умеет заворачивать HTTP/2 в HTTP/3 без дополнительных усилий, поэтому perfscale.su поддерживал HTTP/3 изначально и не требовал отдельного деплоя. Для конечного пользователя это вряд ли станет поводом открыть шампанское, но для сервиса нагрузочного тестирования поддержка актуального транспортного стека выглядит уместно: странно мерить чужую инфраструктуру, если собственная живет в прошлом протокольном сезоне.
Самая полезная часть выпуска — первый postmortem. При одновременном рестарте Keycloak и Nginx во время пересоздания Nginx потерялся Let's Encrypt-сертификат, из-за чего логин на perfscale.ru оказался сломан примерно на 20 часов. По словам автора, агент обнаружил проблему, но быстрой реакции не случилось: в момент алерта он физически не был у компьютера, а позже решил отложить починку до состояния, в котором инфраструктуру чинят головой, а не героизмом. Судя по логам, кроме агента к проблемной ручке никто не обращался, так что пользовательский ущерб оказался минимальным. Домен perfscale.su инцидент не затронул, потому что он работает на другом сервере с отличающимся деплоем.
Для разработчиков и платформенных команд здесь есть два вывода. Первый: WASM-модули Perfscale становятся более пригодными для реальных нагрузочных сценариев, где расширяемость нужна, но лишние 10% накладных расходов неприятны. Второй: даже маленькому инфраструктурному продукту полезно публиковать postmortem с конкретикой — сертификат, Keycloak, Nginx, 20 часов, зона поражения. Это не делает сбой красивым, зато превращает его из тихого фейла в инженерный материал, на котором можно проверить свои алерты, дежурства и процедуру восстановления TLS.