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

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

кажется я не совсем понимаю как делать объемное. я пока следила За временем ответа в зав-сти от кол-ва rows в бд. это не верно?

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

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

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

Скриптом в БД. Всё индивидуально. Возможно не ваш вариант размножать, т. к. логика будет сложная
Сценарий один, просто смотрим зависимость отклика по транзакциям от размера БД

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

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

а это уже зависит от того, какой вам нужен результат и что вы пытаетесь выяснить. вы можете брать по сути любой тест (к примеру, тест со стабильной нагрузкой) и проводить его в одних и тех же условиях, но на  различном  объеме данных. и смотреть тренды, деградируете или нет в зависимости от размера БД

Кол-во строк не всегда может быть однозначно связано с размером БД. Вам бы снять статистику с БД по запросам во время нагрузки. Какие запросы чаще и дольше других выполняются? Условно, если вы вызываете API на вставку чего-либо, перед этим идет поиск, который замедляется с размером БД потому что: запрос неэффективно написан, индекса на поле нет и т.п.
И да, мы всегда смотрели два показателя: кол-во объектов в БД и физический размер.

Питер)))

вот эт интересная тема. я уже создала таску на импорт метрик из перформанс схемы в графану и наш mysql эксперт (у которого нет времени на консультирования нашей системы) выбрал пару графиков. смотрю на них и там инфы нет. если ли у вас пример json такого дашборда который можно  себе взять? хД или мб статья проверенная по которой можно себе эт настроить?

Там где это я делал, мы не использовали графану. Набор bash/питон скриптов + своя визуализация.

Доклад недавно смотрел
http://www.highload.ru/moscow/2018/abstracts/4259

В нем есть описание графиков. И рассказ про OpenSource инструменты: https://www.percona.com/software/mysql-tools

По рассказу они готовые, удобные

@IlyaVladimirovich но по сути вы метрики с перформанс схемы mysql дб брали? значит если они есть то можно и ф графане построить или через парсинг логов делали?>< звучит сложновато  @smirnovqa спасибо. гляну вечером) вдохновлюсь

есть такой вариант эмуляции нагрузки. сделать jmx c топов юзеркейсов и процентным разбиием траффика по даным с прода. поделить трафик с помощью плагина throughput-controller-jmeter и гонять такой тест как soak в течении дней или на разных объема БД (для этого нам все таки нужна копия прода)

У нас был оракл и постгря

Подскажите, кто-то как-то использует jmeter с gitlab'ом в пайплайнах? есть ли возможность плагином или ещё как-то проверять критерии прошел\не прошел теста?

а какие критерии?)