Итак, прошлый выпуск новостей очень понравился аудитории, поэтому я продолжаю делится тем, что произошло с Perfscale. Это продолжение новых фичей из Perfscale. Ксати, эти выпуски выходят раньше на моем проекте на sponsr.
Выпуск №1 - OSS, поддержка QUERY метода и венчурная история
Fix Protocol
Поскольку я работаю в FinTech кампании и мы тестируем FIX protocol то я не могу обойти стороной тот факт, что нам надо уметь нагружать FIX protocol. Поэтому скорость ввода данной фичи был вопросом времени.
Небольшое Предисловие по поводу FIX protocol:
Все брокеры(да, там где акции, котировки, и прочие заумные слова, о которых обычный и здоровый человек не особо вкурсе и слава богу), общаются по FIX протоколу. Этот протокол действует аж с 1992 года и в настоящее время у него 4 версия. Она же[прим. версия 4 FIX Protocol] и широко распространена. Да, TBank и МосБиржа и любая более-менее значимая биржа общаются по FIX protocol. Я в свое время рассказывал как работает FIX protocol на одном из митапов. Может когда-нибудь запишу видео о том, как он работает на пальцах.
Итак, возвращаясь к Fix protocol. В Perfscale я реализовал данный функционал и для теста test.yaml фаил выглядит так
steps: - uses: pro/fix@v1 with: host: fix.venue.com port: 9823 tls: true begin_string: FIXT.1.1 sender_comp_id: CLIENT target_comp_id: VENUE heart_bt_int: 30 messages: - MsgType: NewOrderSingle ClOrdID: order-1 Symbol: EURUSD Side: 1 OrderQty: 100000 OrdType: 1
Но вы можете сказать: а что если хост, порт и прочие данные уже есть и они известны нам, не дублировать же в шагах данные каждый раз. Верно! Для этого я вынес для config.yaml шаг pro/fix-config@v1
before: - uses: std/http@v1 with: url: https://.../FIX44.xml #получаем схему FIX outputs: dict # сохраняем схему FIX - uses: pro/fix-config@v1 with: host: fix.venue.com port: 9823 tls: true sender_comp_id: CLIENT target_comp_id: VENUE schema: "${{ dict.body }}" outputs: venue # сохраняем конфигурацию для переиспользования
В таком случае тот же тест сокращается в несколько раз
steps: - uses: pro/fix@v1 with: connection: "${{ config.venue }}" messages: - MsgType: NewOrderSingle ClOrdID: "ord-${seq}" # уникальный на каждый ордер Symbol: "${choice(EURUSD|GBPUSD|USDJPY)}" Side: "${rand(1,2)}" OrderQty: "${rand(1000,100000)}" Price: "${randf(1.05,1.15,5)}" TransactTime: "${now}" _repeat: 100 # 100 ордеров… _interval_ms: 50 # …по одному каждые 50 мс
А что за seq, choice, и причие значения, спросите вы?
Поскольку тесты у нас могут быть динамическими(например цена выполнения) то без runtime функций помощников никуда. Пока что я стараюсь добавлять их точечно и аккуратно и их кол-во фиксировано
${seq} | Monotonic counter, unique per message send (shared by all fields in that message) |
${uuid} | Random 32-hex-character id |
${now} | Current UTC time, FIX format YYYYMMDD-HH:MM:SS.sss |
${rand(a,b)} | Random integer in [a, b] |
${randf(a,b)} / ${randf(a,b,dp)} | Random float in [a, b], dp decimals (default 2) |
${choice(x|y|z)} | Random pick among the options |
А что за repeat и interval_ms ? Пока это часть шага, поскольку ветвление и циклы я не придумал как сделать аккуратно и элегантно.
попробовать Fix можно только платным клиентам (growing и enterprise), поскольку я не вижу, когда надо тестировать fix на коленке. Как правило это надо кампаниям, которые уже имеют экспертизу на рынке.
Magic Metrics
Метрики — это круто. Особенно мне нравятся метрики, которые привязаны к конкретному прогону. Но есть проблема. Метрики классно смотреть, но не конструировать. Поэтому в Perfscale я сделал «Magic Metrics», которые автоматически подстраиваются к вашим тестам. Например для HTTP(s) это классический p50, p90, p95, p99, latency и прочие а также метрики машин, которые выполняли тест. Если у вас FIX protocol — то это тесты, которые показывют метрики самого FIX (Message rate, Order Rejected rate и прочие метрики).
magic metrics выглядят так (часть):
Magic reporters. Используется Demo машина с посредственными характеристиками
Если вы привыкли делать свои dashboards, то они никуда не ушли: есть Custom Dashboard с теми метриками, которые вы настраивали.
By Test всегда универсальный дашборд и его модификация приводит к изменениям у всех, в отличие от Custom Dashboard.
MCP
Я понимаю, что сейчас ИИ-бум ходит по планете. Отрицать это глупо, поэтому представляю вашему вниманию MCP сервер для perfscale (github: Perfscale/mcp). Он работает как для Open source версии, так и для платной версии.
В бесплатной версии входят следующие команды
run_test | Run a k6/locust/native test (perfscale run), return exit code + parsed summary export |
lint | Validate YAML files (perfscale lint), including typo and action-ID checks |
get_schema | JSON Schema for test or config YAML (perfscale schema) |
parse_summary | Parse raw k6-compatible output into structured metrics |
list_actions | Catalog of native std/* step actions |
list_configs | Recursively list YAML files in a directory, classified test/config |
read_config | Read one YAML file with its detected kind |
write_test | Create/overwrite a test definition, then lint it against the test schema |
write_config | Create/overwrite a run config, then lint it against the config schema |
update_config | Overwrite an existing file only (fails when absent), then lint |
remove_config | Delete a test/config YAML file |
А подключить бесплатно можно через NPM
{ "mcpServers": { "perfscale": { "command": "npx", "args": ["-y", "@perfscale/mcp"] } } }
Или через claude
claude mcp add perfscale -- npx -y @perfscale/mcp
А для платной версии входят следующие команды
whoami | read | Current user, workspace, role, permissions |
tenant_limits | read | Plan, machine/test limits, retention, storage usage |
list_machines / get_machine | read | Machine fleet: status, hardware, agent version, benchmark capacity, region |
list_tests / get_test | read | Test definitions with config JSON |
list_runs / get_run | read | Runs with p50/p95/p99, error rate, RPS, total requests |
get_run_logs | read | Full log output of a run |
runs_by_machine | read | Run history for one machine |
metrics_catalog / query_metrics | read | Available metrics; time-series with label filters |
get_otel_timeseries | read | OTEL metrics collected during a run |
list_dashboards | read | Custom metric dashboards |
list_git_repos | read | Connected repositories and sync status |
list_env_vars | read | Environment variable keys — values are always masked |
audit_log | read | Workspace activity: action, actor, target, time |
run_test | write | Dispatch a test to machines; returns task IDs and log-stream URLs |
sync_git_repo | write | Trigger test discovery for a repository |
Как видите, для платной версии значительно больше команд, но и подключение другое. Сначало надо создать API_TOKEN на странице конфигурации
Создаем токен авторизации
И подключаем уже controlplane-mcp а не OSS
{ "mcpServers": { "perfscale-cloud": { "command": "npx", "args": ["-y", "@perfscale/controlplane-mcp"], "env": { "PERFSCALE_API_URL": "perfscale.su", "PERFSCALE_API_TOKEN": "psk_..." } } } }
Таким образом после подключения можем попросить агента на нативном языке:
напиши тест, который возьмет GET запрос на https://example.com с 10 VU длительностью 30 сек запусти этот тест и какой был p95?
Агент выполнит get_schema → write_test (auto-linted) → write_config → run_test -> читает репорт и забирает метрику p95_ms из репорта.
На сегодня все! Пусть ваши сервисы были зелеными и не падали от нагрузки.
В поисках сотрудничества
Если вы бизнес, которому тяжело и(ли) больно нанимать нагрузочника - то мы в поиске таких заказчиков. Особенно если вы создаете сайты и приложения на заказ то у нас много точек пересечения. Наша платформа доступна от 5000 рублей! (это намного дешевле нанимать нагрузочного тестировщика к себе в штат). Мой контакт в tg - @vitalicset
❤️ Perfscale team!
