Хорошая утилита для Oracle DB: ASH-Viewer

https://github.com/akardapolov/ASH-Viewer

Некоторые команды идут дальше и сохраняют результаты выполнения запросов статистики (как из ASH-Viewer) в InfluxDB, получая непрерывный мониторинг Oracle DB в Grafana. Видел доклад на эту тему от Альфа-Банка

(тут недавно вопрос был по мониторингу Oracle)

какой регламент?

пример задачи или что?

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

Тут зависит от того насколько большая компания, насколько сильно забюрократизированна, и насколько это работает, я встречал компании, где все в порядке с регламентом, но тестирование не построено или проводится для галочки.

Я бы исходил из того, что должен быть отдел НТ контролирующий что, каждый продукт, каждый релиз проводит тестирование.
При этом отдел должен согласовывать, поставщиков услуг, артефакты, планы, найм специалистов, SLA по производительности, подготовку сред, поддерживать инструментарий и базу знаний.

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

Чтобы работало надо описать то, что есть сейчас ;) а потом менять реальность и подкреплять ее регламентом ;)

👍такую тактику я и избрал

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

если интересна организационная часть, вот тут я рассказываю про сервисную команду НТ в Райффайзенбанке
https://www.youtube.com/watch?v=1ZGfN_uBpO8

спасибо, посмотрю!

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

Этапы
Вариант регламента, основан на разделах базы знаний:

0. Подготовка рабочего места
1. Методика
2. Профиль нагрузки, требования
3. Настройка стенда и генерация данных
4. Настройка мониторинга стенда
5. Разработка тестов и заглушек
6. Запуск тестов
7. Анализ метрик и логов, проверка корректности теста и профиля нагрузки
8. Оформление отчётов для себя, инструкций для коллег на будущее и рекомендаций для продуктива

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

Так может проводиться мониторинг или профилирование dev-стенда, если на нем проявляется какой-то дефект - без методики, профиля, стенда, просто мониторинг. Это тоже нагрузка.

Поправка на размер команды
Команда на проекте небольшая. Тест выполняет один человек, не команда. Консультируясь с коллегами.

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

Артефакты
Есть шаблоны профиля нагрузки, методики, отчёта, примеры разных скриптов, подходы к мониторингу, база знаний - это нарабатывалось.

Изначально было только: тесты в git, отчёты с указанием версии в confluence, баги в jira.

Коллеги, подскажите, кто-нибудь сталкивался в контроллере с ошибкой
"abnormal termination caused by mdrv process termination"? Раньше грешили на память: докинули с запасом, все равно возникает. Кол-во пользаков на ступени всего 24. Падает исключительно в одном скрипте, причём сразу все юзеры, что были. Происходит во время выхода на ступень (тест в двух повторностях: первый раз упали 8 юзеров тк работало 6 и заходило 2, второй раз упали все 8 работающих юзеров, а 2 зашли и спокойно начали батрачить)
Только один раз из суммарно 16 вылезла ошибка memory violation, она похоже возникает от сишной функции strcmp (как артефакт, но и о ней сообщаю для полноты картины)
Пока как костыль думаю реранить этих пользователей, раз время ошибки будет заранее известно, но хотелось бы более разумный ответ получить.

а кто то пользовался Remote Desktop Load Simulation Tools? Вообще инфу найти не могу по нему, кроме ссылки на скачивание и 1 книги

чтобы пользователи не падали пачками можно попробовать настроить VU как процессы. а проблема такого рода возникает обычно из за кода на Си, тут нужно разбираться

Добрый день!
Кто-нибудь сталкивался с проблемой, есть ли workaround?:
https://github.com/dcu/mongodb_exporter/issues/122

Telegraf можно попробовать, он собирает метрики mongodb и в prometeus может отправлять

Доброе утро! Пишу нагрузочное для сервиса покупок, использую jmeter. Проблема в том, что до момента проплаты - это наше апи, проплата - апи платежной системы. Апи платежной системы есть у них на сайте, но физически тест план не отрабатывает, так как там необходим их внутренний ключ. Пробую сделать спомощью плагина селениума (инструмент web driver sampler), эмитируя работу на платежной форме, но вместе с апишными сервиами это все не отрабатывает. Может, кто-то сталкивался с такими вещами и подскажет, какие еще возможны варианты решения? Спасибо

ну так это сторонний сервис, его обычно не тестируют, либо ставят заглушку