Привет, я Никита Ковалевский, специалист группы сопровождения, представляю IT сообщество Работяги. В этом сообществе ты можешь поделиться своими проблемами в разработке и найти интересующие тебя вопросы из сферы IT.
Ссылка на первую часть цикла: https://dzen.ru/a/ZdOgiRjmRwV6hg_J
Сегодня мы продолжаем рассматривать возможность ПО JMeter, а именно в данной статье мы рассмотрим взаимодействие с БД на примере базы данных postgres.
В каких ситуациях у нас может возникнуть потребность работы с БД при помощи JMeter? Две ситуации, которые вижу лично я, это работа с высоконагруженной БД и эмуляция работы сервиса с БД.
Рассмотрим пример:
У нас есть высоконагруженная БД, в которой нам нужно выполнить большое количество операций на основе данных, которые у нас хранятся не в БД.
Казалось бы, решение на поверхности – импортируй эти данные в БД в новую таблицу и напиши динамический скрипт, который будет оперировать этими данными, а чтобы не нагружать и без того сильно нагруженную базу используй pg_sleep() между операциями. Да, действительно, в некоторых ситуациях это хорошее решение, но зачастую при работе с БД мы не обладаем полными правами на взаимодействие с ней и банально не сможем создать новую таблицу, к тому же нам еще нужно будет заполнить эту таблицу большим количеством данных, что вызовет дополнительную нагрузку и на без того нагруженную БД. Вот в таких ситуациях на помощь к нам приходит JMeter.
Перейдем к моделированию ситуации и созданию проекта в JMeter.
Предположим:
Есть высоконагруженная БД, в которой есть таблица с пользователями и их номерами телефона. Также у нас есть csv с именами и номерами пользователей. Необходимо обновить номера телефонов пользователей согласно csv, а если пользователя нет, то его нужно добавить.
Ситуация смоделирована, перейдем к реализации.
Первое действие, с которого начнем, это добавление библиотеки для взаимодействия с БД postgres. Для это необходимо в корневом элементе Test Plan добавить jar файл с библиотекой.
Последнюю версию библиотеки можно скачать с maven repository https://mvnrepository.com/artifact/org.postgresql/postgresql/42.7.2
После чего в наш проект необходимо добавить элементы JDBC Request и JDBC Connection Configuration.
Создадим подключение к нашей БД. Для этого необходимо заполнить форму Database Connection Configuration в элементе JDBC Connection Configuration:
Также зададим имя для нашего соединения в поле Variable Name for created pool. Данное имя будет использоваться в дальнейшем, чтобы сопоставить sql запрос с соответствующим подключением.
В двух словах пробежимся по наиболее значимым параметрам в данном элементе
- Max Number of Connections - Максимальное количество разрешенных подключений в пуле. По умолчанию данное значение равно нулю. Если значение равно 0 это означает, что каждый поток получит свой собственный пул с одним подключением в нем, т.е. соединения не будут совместно использоваться разными потоками.
- Pool Prepared Statements - Максимальное количество подготовленных инструкций для объединения в пул на одно соединение. "-1" отключает объединение, а "0" означает неограниченное количество подготовленных инструкций для объединения.
- Test While Idle – отвечает за продолжение проведения тестирования, даже если свободные потоки в БД закончились.
- Validation Query – отправка запроса для проверки функционирования БД.
Перейдем к формированию самого запроса в элементе JDBC request.
Первым шагом в параметре « Variable Name of Pool declared in JDBC Connection Configuration » установим название ранее созданного подключения, затем в параметре Query Type можно выбрать тип запроса (зачастую я про это забываюJ).
Переменные в запросе устанавливаются из уже знакомого нам элемента CSV Data Set Config (см. первую часть цикла).
Также переменные можно задать внутри самого элемента JDBC request, для этого необходимо в теле запроса в местах, куда необходимо установить переменны, поставить знаки «?», после чего указать значения переменных и их типы в параметрах Parameter values и Parameter types.
Забегая немного вперед, обработку ответов на запросы мы будем рассматривать в следующей по очереди статье, посвященной JMeter. Пока что достаточно понимать, что параметр Variable names отвечает за хранение ответа (в данном параметре по порядку через запятую сопоставляются переменные и столбцы из ответа).
Для начала работы с БД практически все готово, но не стоит забывать, что в нашей смоделированной ситуации база данных высоконагруженная, поэтому давайте добавим элемент Constant Timer и установим дилей между запросами. Также давайте в элементе Thread Group установим всего один поток.
Для удобного просмотра запросов и ответов от базы добавим элемент View Results Tree.
Теперь мы готовы к запуску нашего проекта. Запускаем и сразу же видим ошибки… видим ошибки и не пугаемся, посмотрим с чем они связаны.
На самом деле наш проект отработал так, как нужно (вы можете в этом убедиться посмотрев в нужную таблицу в БД), а ошибка связана всего лишь с тем что наш запрос явно не возвращает ответ. Чтобы данная картина не мозолила нам глаза, давайте все-таки установим правильный тип запроса в элементе JDBC request.
После изменения типа запроса запускаем проект еще раз и убеждаемся, что все работает корректно.
В конечном итоге иерархия элементов в нашем проекте будет выглядеть следующим образом
На этом вторая часть цикла статей про JMeter закончена. В следующей части мы поговорим об обработке данных до и после запроса при помощи элементов Pre Processors и Post Processors. Если у вас остались вопросы, то задавайте их в комментариях или на наших ресурсах, наша команда с удовольствием ответит на них).
Ссылки на наши ресурсы – ниже:
