Картинка, отображающая новости: тут и Fix, и Metrics и MCP протокол
Итак, прошлый выпуск новостей очень понравился аудитории, поэтому я продолжаю делится тем, что произошло с 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 машина с посредственными характеристиками
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!
Источник: habr.com