Всех приветствую! В данной статье я не буду пояснять какие-то сложные вещи касательно нагрузочного тестирования. Просто хочется поделиться своей болью, пронесённой сквозь года в разных enterprise системах. Может я не один такой?

Итак, представьте, что вы инженер по нагрузке. Вы каждый день сталкиваетесь с разного рода проблемами, инцидентами, расследованиями. Вы также пишете разного рода нагрузочные тесты, чтобы проверять новые гипотезы и проверять систему всесторонне. В какой-то момент вы понимаете, что просто нагрузочных тестов вам недостаточно. Где-то проблемы с инфраструктурой и вы начинаете создавать дополнительные sh скрипты. Где-то проблемы с самими тестами и нагрузочный фреймворк просто не заточен под выполнение каких-то задач. Например у нас в одном Fintech продукте нам надо было одновременно создавать сделки(сделки порождают открытую позицию), а с другой стороны закрывать старые сделки. Кто работал с биржами возможно узнали в этой концепции CFD сделки. Вот тут начинаются шаманство уже вне "нагрузочного сценария"[прим. здесь подразумевается запуск уже не только самого нагручного теста, но и какого-то помощника(helper) который бы крутился рядом с самим нагрузочным тестом]. Это сложность может увеличиваться сколь угодно много дополнительными скриптами.

И вот в какой-то момент я понял, что не хочу поддерживать или учить другого инженера жить с таким большим набором костылей, которые иногда даже стреляют в самых разных местах. Постоянно надо держать в голове пул машин и кем занят. После долгих размышлений, обдумывания концепций и визуализации через нейросети (именно UI через какой-нибудь v0 строить приятно, говоришь где подправить и сразу видишь результат на фейковых данных) Я сформулировал довольно четкие критерии для себя:

  1. Мне, как инженеру и возможно сисадмину мне надо видеть пул доступных машин(те самые, что запускают тесты).

  2. Мне надо знать, какие есть конфигурации нагрузки. Как будет она запускаться, сколько времени. Это не должны быть сакральные знания, которые зашиты в коде

  3. Сами тесты у нас написаны на разных фреймворках. Есть тесты на Locust, есть K6, есть JMeter. Казалось бы все круто: тесты есть, они запускаются. Но когда дело доходит до создания чего-то быстрого "на коленке" приходится писать тест -> залить в гит -> создать образ и уже только потом запустить его. Почему бы просто не запустить напротив окружения локально? Потому что могут всплыть разные проблемы: например у нас было так, что на маленькой выборке локально все окей, а при запуске 1000+ VUS уже были проблемы. Это все время, время = деньги. Так что возможность быстро собрать и проверить было бы супер крутым решением

  4. Поддержка разных фреймворков - хотелось объединить весь зоопарк и прийти к чему-то одному

  5. Git из коробки (даже не обсуждается). А еще лучше - интеграция с Github/Gitlab.

  6. SSO/SAML - поскольку мало кому понадобится запускать нагрузочные тесты "простым смертным". Да еще и с четким разделением ролей(инженер вряд ли захочет подключать машины сам, к тому же в самой организации у него наверняка не будет прав это делать)

С таким набором непростых критериев я долго думал, что делать(особенно п3 и п4). Целый год мне не давало покоя этот набор критериев. И вот однажды, когда я работал над пет-проектом ко мне пришла в голову мысль. А что если использовать YAML?

Лирическое отступление

Не поймите меня неправильно, мне нравится программировать и вряд ли создатели YAML задумывались о том, как этот язык используют сейчас. Github/Gitlab pipelines, K8S, и terraform (да, terraform не yaml а DSL но я бы сказал, что "вайб" вполне yaml-овский) плотно вошли как язык конфигураций. Даже в Jenkins есть возможность использовать YAML для конфигурации задач. Да, писать скрипты это удобно, гибко, возможность сделать что-то такое "эдакое", чтобы обойти проблемы. Но и вместе с этим это увеличенная сложность, непонимание коллег, которым надо пояснять "почему мы используем X а не Y", нагромождение кода, а порой даже дублирование из-за невозможности переиспользовать одинаковые куски. Я не утверждаю, что на каждом проекте так, если у вас нет этих всех проблем - то вы счастливчики. На моих предыдущих и текущих проектах - нет. Конец лирического отступления.

Далее будет для YAML подразумевается использование его для конфигурирования CI/CD pipelines.

Ведь yaml это:

  • easy to learn

  • есть якори для переиспользования кода\конфигураций

  • есть валидация (это особенно важно для тех, кто пишет pipelines, ведь все параметры помнить не просто)

  • можно быть портируемым для конкурентов например из Github в Gitlab из-за большой похожести

  • маркетплейс с готовыми решениями (привет github actions)

Да, Yaml не обладает той гибкостью, что и языки программирования. Зато YAML можно визуализировать и показать вашему менее техническому менеджеру(которому просто влом смотреть код, ведь помним: время = деньги).

Можно иметь базовый набор YAML шагов(закрытый маркетплейс или std) и расширять его при необходимости.

Далее переходим к тому, чтобы запускать с разных фреймворков. Пришлось для этого делать собственный фреймворк для нагрузки, а уже поверх него делать что-то вроде адаптеров для других фреймворк(K6, Locust, JMeter). из-за того, что это нагрузка то требования довольно суровые, я смотрел в сторону Rust, C, Go или на крайний случай C++. На Rust и Go я писал несколько пет проектов, а вот с C, C++ я не взаимодействовал с момента окончания универа. Поэтому я выбрал то, что знаю лучше (Rust / Go). А чтобы не раздувать кол-во языков и тулинга я выбрал Rust. Все-таки хоть Go и хорош для сетевых вещей а нагрузка как про сетевые вещи в основном, то мне показалось, что на Rust я сделал бы эффективнее по процессору и памяти чем аналог на Go (есть у меня чуйка, что это ошибка. Но доказать я это не могу, кроме борьбы с компилятором!). Итак, вот я сделал фреймворк и уже поверх него начал делать админку (не без помощи друзей в лице claude и codex). После того, как минимальный продукт был готов - подумал, что мне надо какой-то мощный нейминг. Подумал, что раз у нас нагрузка и мы можем запускать нагрузку сразу на нескольких машинах, то самое лучшее, что я придумал - это Perfscale. Perf(ormance) + Scale.

Итак вашему вниманию представляю свой ранний прототип(pre-MVP)

Казалось бы, я пиарюсь? Да! Поскольку мне кажется, что продукт заслуживает вашего внимания! К тому же я не видел никакого платного аналога, который бы поставлял нечто похожее из коробки.

Главный сайт
Главный сайт

Во-первых, это возможность подключать машин(ы) а бонусом еще и запускать тесты сразу на нескольких машинах одновременно, но об этому будет позже

Таблица с подключенными машинами
Таблица с подключенными машинами

При добавлении машины - устанавливается perfscaled - демон-агент, который показывает статус подключение и готовность запустить тест по первому требованию(можно подключать динамические машины через API, но все пока в разработке. Я один а часов в сутках всего 24).

Во-вторых, это конфигурации. Всегда для вас создается несколько готовых конфигураций для закрытия разных потребностей

Name

VUs

Ramp-up

Duration

Debug

1 VU · 1 minute — safe for development

1

1m

Smoke

5 VUs · 30 seconds — quick sanity check

5

30s

Load

10 VUs · 5 minutes — baseline load test

10

5m

Stresss

50 VUs · 5 minutes — high load stress

50

5m

Spike

100 VUs · 1 minute — sudden spike

100

1m

Soak

10 VUs · 30 minutes — extended endurance

10

-

30m

Вот так выглядит конфигурации
Вот так выглядят конфигурации

А вот так выглядит добавление конфигурации. Мне лично очень нравится график Preview поскольку позволяет наглядно увидеть как будет происходить нагрузка.

Вот так выглядит добавление конфигурации.
Вот так выглядит добавление конфигурации.

Также, помним, что у нас тесты могут быть написаны на K6, Locust, JMeter. Для примера вот так выглядит тест на K6

Тест на K6
Тест на K6

Тут можно увидеть все тесты, которые есть в git (сейчас только есть поддержка 1 репозитория с тестами. Но я уже знаю, как это будет выглядеть на UI)

А вот тотже тест но на вкладке YAML

YAML по структуре очень похож на github actions
YAML по структуре очень похож на github actions

Кстати, по поводу запуска самого теста. Его можно запустить на вкладке machines, причем выбрать можно сразу несколько, что удобно, поскольку это позволяет сразу понять, на каких гео у вас проблема(в случае, если у вас есть разные GEO). А еще можно заметить Визуальнй редактор. Пришлось выключить его на какое-то время, пока не получится красиво отображать более сложные тесты.

Запуск теста на нескольких машин одновременно
Запуск теста на нескольких машинах одновременно

Осталось последняя мощный функционал показать: роли и их редактирование. изначально есть 4 роли: owner, admin, ,manager и qa и у всех разный набор опций

Роли живут на вкладке access controls и их можно настроить "под себя"
Роли живут на вкладке access controls и их можно настроить "под себя"

Казалось бы, что еще нужно. А нужно много чего еще и без вашей помощи, обитатели хабра, мне не справиться. Дело в том, что проект развивается на мои(не бесконечные) ресурсы. Я действительно считаю, что аналогов на рынке такому продукту нет. А что по тарифам и ценам?

Цен пока нет, поскольку в поисках первых клиентов. Тарифы для первых клиентов будут значительно ниже, чем будет потом показываться на сайте. Поэтому если вы CTO компании, собственник веб студии, которым надо нагрузить и сделать это не дорого - то можете написать мне на почту о вашей проблеме (vitali.haradkou@perfscale.su). Также хочется отметить то, что цена складывается только за хранение результатов теста.

Буду рад обратной связи в канале @haradkou_sdet или в коментариях! Сделаем нагрузочное тестирование доступным для всех!

P.S. я в поиске людей, кто готов(пока за идею и % от компании) присоединится к данному проекту. Актуальные вакансии есть на perfscale.su/jobs. Глобально я в поисках человека, кто поможет с B2B продажами, а также CTO, поскольку моя экспертиза не бесконечна. Все таки я инженер по автоматизации и нагрузке.

P.P.S. Хабр не дает опубликовать статью в секации "я пиарюсь" не имея кармы >30, поэтому просьба понять и простить.

UPD: Справедливо заметить, что у моего продукта также нет функционала с одновременным запуском помощников о чем говорилось в начале статьи. Решил не упоминать об этом, поскольку данный функционал уже в разработке, но не доведен до ума.

Комментарии (0)