
Приветствую, любители нагрузки. Для истории прошлые выпуски
Эта неделя открывает долгожданные фичи, начнём с OSS части:
GRPC
В третьем выпуске я намекал, что после Websocket на очереди gRPC. Так вот — он здесь. Теперь perfscale умеет гонять не только REST, WebSocket и FIX, но и полноценный gRPC: unary, client/server streaming и bidi. Схема подтягивается либо через reflection, либо через descriptor‑файл — на выбор.
Простой unary‑вызов выглядит так:
steps: - uses: std/grpc@v1 with: url: grpc://api.example.com:50051 service: api.OrderService method: CreateOrder proto: reflection: true payload: customer_id: "cust-${seq}" items: - sku: "SKU-${rand(1000,9999)}" qty: "${rand(1,10)}" check: status: OK json: { order_id: "${exists}" }
А если вам нужен streaming — используйте отдельные шаги жизненного цикла, как и с Websocket:
std/grpc-connect@v1— устанавливает соединениеstd/grpc-send@v1— отправляет сообщение в потокstd/grpc-recv@v1— читает до stopping rule (until_json, until_contains или количество)std/grpc-close@v1— закрывает поток и соединение
Метрики, которые теперь доступны из коробки:
grpc_req_duration— полный цикл unary‑вызова (p50 / p95 / max)grpc_stream_duration— время жизни стримаgrpc_msgs_sent/grpc_msgs_received— throughput по сообщениямgrpc_streams_active— одновременно открытые стримы
Кстати, reflection работает не со всеми серверами (кому‑то безопасность не позволяет), поэтому descriptor‑файл через proto: { file: "service.pb" } — план Б.
Child Process
Вторая фича этой недели в OSS — std/child_process@v1. Теперь из нативного YAML‑теста можно запустить дочерний процесс: поднять mock‑сервер, fixture‑базу, sidecar — всё, что нужно SUT. Процесс живёт across the run, step возвращается сразу после readiness‑гейта.
Важно: нужно явно разрешить процессы в конфиге через allow_process_actions: true.
Пример — поднимаем Python HTTP‑сервер перед тестом и гасим после:
# file: config.yaml before: - name: web uses: std/child_process@v1 with: command: python3 args: ["-m", "http.server", "8080"] waitUntil: port_open: 8080 timeout: 10s restart: on-failure max_restarts: 3 outputs: web after: - name: stop web uses: std/kill_process@v1 with: name: web signal: TERM grace_ms: 5000
И сам тест:
#file: test.yaml steps: - uses: std/http@v1 with: url: "http://127.0.0.1:8080/health" check: status: 200
Что умеет std/child_process@v1:
port: 0— авто‑назначает свободный порт и экспортирует его в дочерний процесс как PORTwaitUntil— ждёт readiness по stdout_contains, stderr_matches, port_open или их комбинацииrestart— never (default), on‑failure или always с max_restarts и backoff_msbuffer_kb— размер tail‑буфера для stdout/stderr (default 64 KiB)Авто‑убийство — что бы ни случилось (нормальный финиш, упавший before:, Ctrl‑C), perfscale прибивает все запущенные процессы автоматически:
SIGTERM→ grace period →SIGKILL, целиком process group. Забытый kill_process не забирает ресурсы после тестов.
А std/kill_process@v1 останавливает процесс по имени (рекомендуется) или raw pid. tree: true (default) шлёт сигнал всей группе. На Windows raw pid не поддерживается, а tree игнорируется — убивается только direct child.
Кстати, под капотом k6 и Locust в perfscale всегда были child processes. Разница теперь в том, что вы можете управлять своими собственными процессами с теми же гарантиями: readiness‑гейты, рестарт‑политики, tail stdout/stderr и корректное завершение.
Fixed Triggers
А теперь про платформу. Долгое время тесты в Perfscale Platform запускались в основном из CI (GitHub Actions, Jenkins, CircleCI) или руками через UI. Триггеры какое‑то время работали некорректно. А теперь прямо на платформе — вы можете прям задать условия, по которым прогон стартует сам.

Бонус пункт
А еще, что касается perfscale платформы: это работающие платежи для https://perfscale.ru. После подключения к ЮКасса я наконец‑то могу выставлять счета не только организациям.
Github: https://github.com/Perfscale/perfscale
Docs: https://perfscale.ru/docs
Site: https://perfscale.ru
Давайте сделаем нагрузку лучше!

