Perfscale news #10. Shared variables, Pub/Sub load testing & live metrics

Об авторе, кто он такой и что делает можно почитать тут. Пост специально открыт для всех, чтобы не было проблем с разным уровнем доступа.

Приветсвую, любители нагрузки и добро пожаловать в юбилейный 10 выпуск. Прошлые выпуски можете найти ниже

• Новости Perfscale № 1
• Perfscale news #2: Fix Protocol, Magic metrics и MCP
• perfscale news #3 Websocket, Inference, NPM
• Perfscale news #4. GRPC, Fixed Triggers, Child Process
• Perfscale news #5. SQL, thresholds и оптимизации
• Perfscale news #6. GraphQL, поддержка Import, и метрики
• Perfscale news #7. Fix Import, SOAP, and more HTTP metrics
• Perfscale news #8. WS Benchmark, Jmeter open sourced & Fixed linked accounts
• Perfscale news #9. GPU, LLM, Docker images

И сразу врываемся в 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% и держаться в тонусе в этот осенний дождливый период.