JMeter: нагрузочное тестирование бaзы данных Часть II

JMeter – отличный инструмент для нагрузочного тестирования базы данных. Но для отлаженной работы, необходимо настроить два основных элемента  приложения.

О том как настроить JDBC Connection Configuration и о части настроек пула из этого раздела мы уже говорили в нашей предыдущей статье «JMeter: нагрузочное тестирование бaзы данных Часть I».

Сегодня мы расскажем о конфигурации двух последующих секций Connection Validation by Pool и Database Connection Configuration, а также поговорим о втором элементе JMeter JDBC Request.

Connection Validation by Pool — это настройки для контроля корректности сессий. Наш пул с некоторой периодичностью делает запрос из поля Validation Query. В случае если сессия некорректна, пул просто её перезапускает. Допустим, в процессе теста перезапустить базу данных, то пул просто пересоздаст коннект прямо во время теста.

И последняя секция Database Connection Configuration. тут с помощью URL’а можно сразу задать хост, порт и имя базы данных, с которыми будем работать.

Второй элемент JMeter — это JDBC Request из раздела Samplers.

Добавляем запрос Thread Group-> Add -> Sampler -> JDBC Request.

Далее пишем собственно сам запрос:

Этот элемент очень прост. Существуют два основных типа запросов к базе данных: Statement и Prepared Statement. Разница состоит в том, что sql-запрос это не просто строка с командами и данными, а объект (Java-объект или просто сущность ООП) с определенной структурой, который собирается на клиентской стороне и разбирается на стороне сервера. Каждый раз создавать такой объект нам не надо. Необходимо просто иметь некий шаблон запроса, куда будем подставлять необходимые значения и отправлять на исполнение серверу.

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

Prepared Statement имеет и свои минусы. Хранение шаблона сходно кэшированию. Этот кэш хранится в JVM-heap . Необходимо создавать Prepared Statement на каждый шаблон запроса и на каждый коннект к БД. И чем больше коннектов у нас используется, тем больший размер кэша нам необходим. На выполнении длинного теста такой кэш может быстро перейти в Old Generation и, при наличии достаточного объема памяти, работать с ним гораздо быстрее. Что, согласитесь, удобнее. Но, если памяти будет недостаточно, то Jmeter, увы, подвиснет и упадет. В этом случае есть возможно распаралеливания запуска тестов Jmetr-ом на разных машинах.

А Statement объекты — будут постоянно пересоздаваться объекты в New Generation.

Добавляем необходимые отчеты:

Тhread Group-> Add → Listener ->View Results Tree ,

Thread Group-> Add → Listener → Graph Results,

Thread Group-> Add → Listener → View Results in Table

Сохраняем, Ctrl+E b Ctrl+R и смотрим графики!