Приветсвую, любители нагрузки и добро пожаловать в юбилейный 10 выпуск! Прошлые выпуски можете найти ниже
Прошлые выпуски
И сразу врываемся в OSS версию
OSS
Shared variables
У нас появились shared variables для того, чтобы делить переменные между VUS. Например вот так мы объявляем общие переменные
# config.yaml vus: 8 duration: 30s shared_variables: pending_orders: [] # list → append / pop / length_gte approved_count: 0 # number → increment last_error: null # any → set / get
А меняем их вот так
# producer.yaml — every iteration enqueues one order steps: - name: enqueue order use: std/set_shared_variable@v1 with: name: pending_orders op: append value: { id: "ord-${seq}", total: "${randf(10,100,2)}" }
Где
name: это имя переменной
op: append, pop, или length_gte или length_lte
А что, если у меня есть тест, где надо читать и писать в shared variable? Тогда придется использовать именно список, поскольку для автомарных вещей(строки, числа) эта опция для вас недоступна, поскольку требует «синхронизатора». Этим синхронизатором выступает Redis драйвер, которого в OSS нет, зато есть в perfscaled (Perfscale Platform). Да, это тоже один из seller point в пользу perfscale platform.
Кстати, вот пример с shared variable для тех, кому все‑таки надо писать тесты, с shared variable. «Все 10 VU пишут + читают (общий пул)» ‑ просто append/pop в одном test.yaml, и гонок у вас нет, а каждая операция атомарна:
#config.yaml shared_variables: pending_orders: []
И сам тест:
steps: - use: std/set_shared_variable@v1 with: { name: pending_orders, op: append, value: { id: "ord-${seq}" } } - use: std/get_shared_variable@v1 with: name: pending_orders op: pop wait_for: { length_gte: 1, timeout_ms: 10000 } extract: { order_id: $.id }
Pub/Sub
Итак, теперь вы еще можете тестировать ваши очереди сообщений почти нативно. Вот пример такого теста
# test.yaml steps: - name: order events roundtrip use: std/pubsub@v1 with: driver: nats url: nats://127.0.0.1:4222 subject: orders.created publish: - '{"id":"ord-1","total":42.50}' - '{"id":"ord-2","total":17.00}' subscribe: count: 2 # wait for both messages until_contains: '"id"' # each counted message must match timeout_ms: 2000 check: body_contains: ord-2
Здесь мы и подписываемся, и публикуем сообщения. Самый простой тест. А если нам надо задерживать сообщения? что‑ж, тут есть 2 варианта.
Это контроль через sleep
# producer.yaml steps: - name: produce order event use: std/pubsub@v1 with: driver: nats url: nats://127.0.0.1:4222 subject: orders.created publish: - '{"id":"ord-${seq}"}' - use: std/sleep@v1 # пауза между сообщениями with: ms: 100 # раз в 100 мс на VU
И конфигурация
# config.yaml vus: 4 # 4 VU × 10 msg/s = 40 msg/s суммарно duration: 30s
контроль через arrival‑rate
# config.yaml — 10 итераций/сек = сообщение каждые 100 мс (rate = 1000/N) arrival: max_vus: 50 pre_allocated_vus: 10 stages: - { duration: 30s, rate: 10 } # 10 msg/s; rate: 0.5 = раз в 2с
И Sleep в тесте не нужен. Поскольку частота теста зависит от rate + duration
А что, если у меня Kafka/Redis? Как с ними быть? Если у вас Kafka/Redis то эти драйверы доступны только в pro версии. Поскольку это дополнительные зависимости в сам OSS движок а его не хочется перегружать всеми возможными вариациями pub/sub драйверов.
Live metrics
Фича больше делалась для Perfscale Platform(Controlplane). Но никто не мешает отправлять метрики вот так
# config.yaml vus: 50 duration: 5m report: url: perfscale.su # или свой "приёмник". Для perfscale OSS это не будет работать!!! during_run: true # стримим снапшоты каждые 5с interval_ms: 5000 batch_size: 500 # default max_cpu_percent: 90 # не отправлять репорт, если наш CPU > 90%
И предвосхищая ваши вопросы(Q&A):
Q: Батч получился больше batch_size / батчи не успевают уходить?
A: batch_size: 500 ‑ это триггер отправки («отправить, как только набралось 500 сэмплов»)
Q: Т.е. я не получу метрики, если у меня процессор забит?
A Метрики не получишь. Батчи будут дропаться. Проблема известная, и пока что это осознанный выбор.
Q: могу ли я сделать свой сервер для метрик и подставить не perfscale.su?
A: Да, так и задумывалось изначально. А для controlplane там стоит perfscale.su/.ru. Но также доступна отправка на Prometheus или другую систему мониторинга(ELK стек например). Это настраивается в perfscale platform во вкладке «интеграции». А сам config.yaml будет намного чище.
Q: А что насчет perfscale serve команды, учитывает ли live metrics?
A: да, но надо держать одновременно perfscale serve и уже после выполнять команду perfscale run ‑с config.yaml ‑f test.yaml
Perfscale Platform
Во‑первых, как можно узнать по названиям, все фичи в этом релизе больше относятся к Perfscale Platform, поскольку больше дают преимущества, если у вас платная версия.
Во‑вторых, перерабатывается визуальный редактор. Теперь он более приятный, но все еще находится в «ранней бета версии», его вы можете увидеть в конце блока
Shared variables
Для тестов включены такие драйверы, как kafka и redis. Т.е. это более точные отправки, в «обход» общего драйвера nas. Все драйверы уже включены в perfscaled агент. А синхронизатор для perfscale.su/.ru уже написан. Т.е. вы можете запустить несколько тестов. и даже для атомарных операций. Все будет работать из коробки. Это прямо жирный бонус, что не надо запускать 2 теста таким образом, что у нас будет
Pub/Sub
Поскольку мы уже начали говорить про pub/sub, то стоит снова напомнить о том, что для perfscale platform у нас сделано поддержка kafka и redis драйвера.
# producer.yaml steps: - name: produce order event use: std/pubsub@v1 with: driver: redis. # redis driver url: redis://127.0.0.1:4222 # сслыка на redis. В примере localhost subject: orders.created publish: - '{"id":"ord-${seq}"}'
По скромным замерам погрешность по сравнению с NAS драйвером на уровне 3-5% в пользу нативного драйвера. Мелочь, а приятный бонус «из воздуха».
Live Metrics
Эта фича уже встроена, и как и было написано до этого. Если у вас, например, настроена интеграция для Prometheus, то конфиг менять не надо. Все будет автоматически работать.
Как и обещал. Вот так выглядит редактор. Менять местами шаги пока нельзя, и больше подходит для сравнения того, что вы написали. Но все еще впереди
А на этом у меня все. Как всегда, желаю вам здоровья физического и ментального на уровне 99,999% и держаться в тонусе в этот осенний дождливый период.
