Это был следующий шаг

Лол
Мне пришлось начинать свой путь в тестировании с разработки плагина для Jmeter. Говорят этот инструмент стал одной из причин начала второй мировой. Немцы вроде до сих пор негодуют, но я все-таки решился.

Все четенько, но есть одно но: при разработке сценария - сложно проследить датафлоу, т.к. не получается десереализовать сообщения :(

Если тебя интересуют инструменты то мы используем этот плагин https://github.com/phiSgr/gatling-grpc

https://github.com/tamediadigital/grpc-gatling вот ещё есть

Оффтоп в поддержку настроений чата.
Про Германию и жыметер эт конечно ппц лирика 😂

Выбрал жиметр, т.к. java немного практикую. Гатлинг тоже рассматривал.
Гляну, спасибо 🙂👍

Василий Кудрявцев  - я думаю здесь есть?

У меня вопрос по курсу на otus: возможно проходить курс если работаю (функциональные тесты ) на Javascript? k6.io вроде как в программе заявлен. А вот ни С ни Java никогда не использовал.

в личку

Всем привет.
Вопрос по теме тестирования grpc:
Хочу протестировать бизнес логику, которая полностью на grpc.
- Половина происходит в мобилке - из неё можно достать логи в logcat'е, и там все в человекочитаемом виде.
- Другая половина же - в браузере, в закодированном виде (grpc-web-text) - Вот с ней и проблемка - не получается десериализовать.

Как вообще у вас происходит отладка grpc при разработке сценария? Или это лишнее, и следует сесть с одним из разработчиков и вручную собирать и тестировать параметры для каждого запроса?

Привет! Подскажите, есть ли у кого-нибудь опыт нагрузки rabbitmq, какую макс. нагрузку он может выдерживать?
У меня проект имеет несколько вариантов развертывания, в т.ч. через кролика, в требованиях есть показатель нагрузки - 1000tps (это требование выдерживается при standalone версии), при версии с кроликом более 140 tps, не получается
Есть ли у кого-нибудь подобный опыт?

был опыт несколько лет тому назад, навскидку помню, что есть зависимость от размера сообщения - чем меньше размер тем быстрее может обрабатывать и ещё есть предел для одной очереди, т.е. увеличивая их число можно увеличивать пропускную способность, насчёт типа брокера уже не помню влияния

Если считать по сообщениям проходящим через кролика, то у меня было до 20к и упирались не в него, но там один исходный запрос создавал сообщения в несколько очередей. Но и на входе было не меньше 1к точно.

Привет
вроде как дофига он может держать
но тут нюансы в администрировании + смотря как в него грузить эти данные

мы объединяем однотипные сообщения в батчи и шлем уже их
это в разы быстрее чем поштучно слать

больше ничего не подскажу увы

Если нужно через очереди большие данные прокачивать - то их стоит класть в любую бд, а через очереди передавать только id строки в бд

Само сообщение весит 770 байт
в том-то и дело, что обмен сообщениями через нескольок очередей или формирование пачек сообщение софтом не предусмотрено

Вот тут почитал, если правильно понимаю, кролик может выдерживать до 120000tps, так что пойду к админам
https://github.com/johnlonganecker/rabbitmq-performance-app

Вот есть доклад о том как можно пооптимизировать раббит, но основное Вам уже подсказали на счёт батчей https://youtu.be/jMZviSKf3QU

Посоветуйте что-то для нагрузочного тестирования API / UI пожалуйста.
Планируется это внедрять и клиент рассматривает все от опен соурс к платным тулзам. Интересует особенно негативный опыт использования того или иного инструмента. Знаю что звучит как поисковый запрос гугла, я еще буду сам POC для каждой тули делать, но я не ожидал что на рынке их аж столько много)

нагрузка UI странный кейс