Что касается пустой бд - это бесполезная идея.

Производительность ОЧЕНЬ часто зависит от объёмов бд

Понятно. А замокированные обращения к внешним сервисам не сильно исказят картину?

От заглушек зависит.
В идеале нужно выяснить времена ответа реальных систем и моделировать их в заглушках

Понял, спасибо

Про бд:

Тут такие дела: представьте, что бд - это книга.

Писать что в пустую, что в набитую книгу (таблицу) - примерно одинаково.

А вот скорость чтения ОЧЕНЬ зависит от объёмов таблицы. Потому что вычитывается либо вообще вся таблица, либо Нужно сперва найти ту часть, которую нужно прочитать.
Быстро вы найдёте в «война и мир» нужный кусочек по конкретной фразе?

Чтобы быстро читать - придумали индексы (как оглавление или алфавитные указатели в книгах).

Но чем больше индексов - тем медленее запись, ведь нужно внести информацию не только в саму таблицу, но и в индекс.

При этом чем меньше таблица, тем проще добавить данные в индекс, ведь индекс это по сути просто нужная часть таблицы, которую взяли ещё раз и отсортировали по порядку по указанному вами принципу

Было в таблице «1», «3»
Вы вносите туда «2», получается «1», «2», «3»

А если было несколько миллионов значений - сперва надо найти, куда вставлять.

====

Если что сама контейниризация тоже нормальный сценарий. Но надо учитывать что в идеале тестировать нужно еще или дополнительно на том же количестве инстансов что и прод

Коллеги, а какие есть способы пушить сообщения в жметер?

Сейчас я использую pull - жметер стучится во внешнюю систему и ждёт ответа.
А как можно это сделать обратную модель?

Я меня пока только дурная идея: подписываться на очередь rabbitmq, где для каждого потока своя очередь

(реббит у нас - часть системы и pull-ить через него вполне возможно, но идея каждому потоку делать свою очередь мне не нравится. Может и без него можно?)

Http simple table server вроде тут не поможет, так?

Да, занимался.
Lol будет, если вы работаете на моём же проекте. Но коллеги переписывали его с WCF/MSBin1 на HTTP/REST

Уйти от Visual Studio не получится. С полным .NET она хорошо работает. WCF клиент есть и в .NET и в .NET Core, технически можно попробовать использовать и Core и найти какой-нибудь новый инструмент на Core.

Или просто написать утилиту "бешеный пользователь" которая будет подавать нагрузку. Без всяких JMeter/Visual Studio. Первые 100 дефектов мы в команде такой утилитой и находили

А коллеги в соседнем отделе запускали автотесты в 20 потоков и тоже были довольны

Не, найти куда вставлять замёт что-то порядка Ω(n log n), столько же, сколько просто найти позицию сортированного массива. Поскольку функция логарифмичесская, итоговое время поиска (число итераций) слабо зависит от объёма массива. А вот то, что все последующие позиции сдвинутся на +1 по одному индексу — это надо перезаписывать, есть прямая зависимость от объёма массива. А если сортировка по большему числу полей — то ещё больше.

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

а я как написал?)

чет не проснулся похоже до конца😅, соррян

:)

Добрый день, подскажите есть ли у кого то хороший мануал по тому как разбирать jfr отчеты?

Спасибо!
Незнание математики меня подводит :(

Но практически - получается, что писать в объёмный индекс всё равно медленно, или это зависит от типа индекса (нужно/не нужно сдвигать)?

Не знаю ответа :(

Я ещё не разбираюсь в БД настолько хорошо, может быть там есть какие-то штуки, позволяющие это обойти. С другой стороны, точно знаю, бывают кейсы когда при интенсивности операций по БД выше некоторого порогового значения СУБД начинает забивать на индексы вообще. Интересная тема, курить-неперекурить 🙂

Начал смотреть, кажется, что на практике цена записи в таблицу с индексами будет, в лучшем случае, линейно кратна объёма таблицы, т.к. бинарные деревья, связанные списки и всё такое.
Поскольку индекс — суть позиция поля в сортированном массиве таких же полей, добавление нового поля не может не сдвинуть все позиции, идущие после.