я пока балуюсь, выставил 1000 потоков, смотрю что происходит, вроде ничего не умирает

просто тратишь впустую оперативку

свою

ага, не все ж хрому отдавать

😂

А кто-нибудь ещё занимается перфомансом в Microsoft visual studio?)) Просто недавно начал входить в это всё, и достался по наследству проект в студии) Интересно, кто ещё такие боли испытывает

И ещё хотел узнать, jmeter с wcf, в которых msbin content type подружить насколько больно? Я так понимаю готовых решений нет? Сорри, если как зелень выражаюсь, ток вхожу в нагрузочное тестирование

Боль и печаль)

Вроде нашел с sqa days митапчик, дружить дотнет с джиметром это, конеш, квест

А, лол, это же митап от Вячеслава Смирнова))

Мы использовали другой подход:
Написали на c# прогу-конвертер:
Мы ей из jmeter шлём xml - она нам возвращает msbin1.
Мы ей msbin1 - она нам xml

В итоге если запрос msbin1 не нужно параметризовать, мы его отправляем как есть (кажется, из файла)

А если нужно - мы пуляем xml в конвертер, а вернувшийся msbin1 отправляем уже в систему. Ответ системы отправляем в конвертер и читаем ответ в xml

Изначально хотели написать конвертер так, чтобы он сам слал запросы прямо в систему, но не осилили авторизацию.

Ps Для отладки удобно использовать fiddler с плагином для silverlight - он сразу показывает трафик в виде xml.

Всем привет! На сколько ужасно звучит идея НТ изолированного сервиса? Т.е. сервис запускается в контейнере, бд к ниму тоже в отдельном контейнере - пустая. Внешние сервисы замоканы. Такое вообще практикуется😊 ? По мне, так таким образом мы ничего не проверим, кроме может  корекнтой работы с потоками в самом сервисе

Тестировать на проде можем, но возможность будет крайне редко

Мб раз в год. А держать среду приближенную к бою накладно как то получается

Еще есть вариант, все таки базу с сопоставимым с боем объемом данных использовать

Контейнеры перпендикулярны изолированному НТ, которое само по себе обычное дело. Только проводить такое НТ можно исключительно как дополнение к интеграционному. Понятно, что обычно всё равно мокается часть интеграций, но учитывая принципиальную невозможность идеальной корреляции полученных результатов к таковым, предлагаемым на ПРОМе, следует максимально близко повторять ПРОМовскую среду. То же касается контейнеров.
Накладно/ненакладно - так вопрос не ставится. Или результаты в первом приближении надёжные, или вот, что-то потестили, как-то работает.

Все зависит от цели и объекта тестирования. Если объект тестирования ровно вот этот сервис, тогда правильно исключать его интеграции и ставить заглушки. Иначе может быть ситуация когда ты упираешься в производительность интеграции - в выводах придется писать что дальше оценить производительность объекта невозможно.
но если по этим тестам надо оценивать прод, то нужно базу догонять по объему как минимум. искать корреляции с продом различными видами сайзинга

плюс оценивать влияние интеграции, распухшей бд

Изолировать сервис - норм.

А вот если вы его размещаете в контейнере, которому выделено меньше ресурсов чем проду - то результаты можно будет интерпретировать только в одну сторону:

- «производительность на проде столько же или больше»

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