Нагрузочное Тестирование Postgresql С Использованием Jmeter, Яндекс.танка И Overload

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

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

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

1. Apache JMeter — это инструмент нагрузочного тестирования, который способен запускать тесты для соединений JDBC, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP «из коробки», а также многих других протоколов и решений с использованием различных плагинов.

2. Яндекс.

   Танк — облачный инструмент нагрузочного тестирования, использующий различные генераторы нагрузки, в том числе JMeter.

3. Яндекс.

   OverLoad — сервис для удобного мониторинга и анализа серверов под нагрузкой.

Установка и настройка

1. Монтаж 32-битная версия Java.
2. Монтаж 64-битная версия Java.

Для первоначальной настройки будет достаточно внести всего одно изменение.

Идем по пути apache-jmeter-2.13/bin и открываем файл jmeter без расширения для редактирования:

cd apache-jmeter-2.13/bin nano jmeter

Найдите строку, как на скриншоте ниже.

Значения размера кучи задаем в соответствии с характеристиками используемого сервера.

Первое значение HEAP Xms — это объем ОЗУ, выделяемый процессу при его запуске, а второе Xmx — максимальное значение ОЗУ, которое будет доступно процессу.

Если сервер не имеет графического интерфейса и доступ к нему осуществляется удаленно, как в большинстве случаев, лучше установить JMeter локально для отладки и написания скриптов.

В идеале версии должны совпадать, но в большинстве случаев JMeter понимает скрипты соседних или минорных версий.

Конечно, на локальной машине также должно быть Джава и я JMeter .

Перейдем к установке и настройке Яндекс.

Танка, для этого достаточно выполнить следующие действия:

sudo apt-get install python-pip build-essential python-dev libffi-dev gfortran libssl-dev



sudo -H pip install --upgrade pip



sudo -H pip install --upgrade setuptools



sudo -H pip install https://api.github.com/repos/yandex/yandex-tank/tarball/master

Далее нам нужно указать нашему пистолету, куда и чем стрелять.

Для этого создайте на машине с баком рабочий каталог с конфигурационным файлом load.ini.

mkdir test cd test nano load.ini

Содержимое конфигурационного файла является руководством к действиям танка; он должен отражать все ключевые моменты теста.

Вот пример load.ini для теста с использованием JMeter:



Думаю, в блоке [танков] всё понятно; если возникнут вопросы, есть описание каждого поля и блока от самих танкистов.

Все самое интересное находится в блоке [jmeter].

Параметр jmx содержит путь непосредственно к скрипту, jmeter_path — путь к исполняемому файлу JMeter, а чтобы танк не совершал лишних движений, в параметре jmeter_ver нужно указать версию JMeter.

Разработка сценария

Как начать осваивать JMeter и одновременно понимать его GUI, хорошо написано в Эта статья .

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

Первое отличие состоит в том, что PostgreSQL не поддерживается в JMeter «из коробки», поэтому вам необходимо скачать драйвер необходимой версии.

Затем вам нужно поместить скачанный .

jar в каталог /lib в папке с JMeter. Тот же .

jar нужно разместить по аналогичному пути на машине с баком.

Теперь, когда с драйвером разобрались, перейдем к скрипту.

Первое, что вам нужно сделать, это настроить соединение с базой данных; для этого щелкните правой кнопкой мыши План тестирования -> Добавить -> Элемент конфигурации -> Конфигурация соединения JDBC. Дерево тестов пополнится элементом конфигурации, как на скриншоте:



Зайдя на него, мы увидим множество необходимых полей.

Здесь нужно обратить внимание в первую очередь на верхнюю часть:



Здесь важно заполнить поле Имя переменной.

Это имя будет использоваться в запросе JDBC (сэмплер) для доступа к пулу сеансов.

Также стоит обратить внимание на максимальное количество подключений; этот параметр ограничивает количество одновременных подключений к базе данных.

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

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

Шаблон такой:

• URL-адрес базы данных: jdbc:postgresql://IPAddress:PortNo/DatabaseNameЭautoReconnect=true ;
• Класс драйвера JDBC: org.postgresql.Driver;
• Имя пользователя: имя пользователя базы данных;
• Пароль: пароль базы данных.

Нажмите «План тестирования» -> «Добавить» -> «Потоки (Пользователи)» -> «Группа потоков» еще раз.

Перед нами панель управления стрельбой, здесь мы вводим количество пользователей - Number of Threads, сколько времени потребуется для достижения Ramp-Up Period и с какой интенсивностью будет повторять каждый новый пользователь вместе с предыдущим действия.

Если нам нужно отправлять запросы бесконечно, установите флажок «навсегда» рядом с Loop Count. Для первого теста можно задать значение паре пользователей, с небольшим количеством повторений.

Теперь перейдем непосредственно к запросам в базе данных.

Чтобы добавить в тест план сэмплера запроса JDBC, щелкните правой кнопкой мыши нужную нам группу потоков -> Добавить -> Сэмплер -> Запрос JDBC. Изначально нас интересует поле «Имя переменной»; он должен соответствовать аналогичному параметру из конфигурации соединения JBDC. После этого смотрим выпадающий список Query Type, в зависимости от вашего запроса здесь должно быть соответствующее значение, например для запроса SELECT в базе данных нужно выбрать Select Statement, а для INSERT COPY и UPDATE — Оператор обновления, как в нашем примере.

В конце работы с этим семплером нам необходимо задать тело запроса, которое должно соответствовать валидному SQL-запросу.

В общем скрипт готов, но нам нужно его отладить, делается это так:

• Добавьте Debug Sampler в нужную группу потоков после запроса JDBC. Он отобразит ответ, полученный после запроса к базе данных.

  Добавляется аналогично предыдущим элементам Thread Group -> Add -> Sampler -> Debug Sampler;

• чтобы увидеть результаты конкретного семплера, в конце плана тестирования нам нужен мониторинг результатов — он добавляется так: Test Plan -> Add -> Listener -> ViewResults Tree. При запуске скрипта появится подробная информация обо всех выполненных запросах.

После запуска скрипта я получил следующие результаты:

Отладка скрипта

Итак, переходим к параметризации.

Есть много способов сделать это, наиболее уникальным из которых является параметризация с помощью BeanShell PreProcessor. Для этого нам нужно вставить вышеуказанный препроцессор перед нашим запросом JDBC — Группа потоков -> Добавить -> Препроцессоры -> Препроцессор BeanShell. Вы можете прочитать о препроцессорах здесь или в Веб-сайт ДжМетер.

BeanShell PreProcessor не рекомендуется использовать при больших нагрузках; для стабильного и быстрого варианта используйте JSR223 PreProcessor + Groovy.



Здесь нет излишеств — пишем на java, импортируем нужный класс, объявляем переменную, присваиваем ей случайную величину нужного формата.

Чтобы поместить полученную переменную в переменную JMeter, используйте vars.put().

Теперь перейдите к нашему JDBC-запросу и добавьте переменную в формате ${needUUID} вместо значения в уникальном поле, пример на скриншоте ниже:



Окончательная структура нашего плана тестирования выглядит так:



Сделаем еще один запуск из JMeter, сразу посмотрим ViewResults Tree, выберем Debug Sampler и перейдем на вкладку Response Data:



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

Когда тест отлажен и готов к запуску, нам необходимо удалить из него элементы отладки, а именно Debug Sampler и ViewResults Tree. Это можно сделать, просто щелкнув правой кнопкой мыши по элементу и выбрав «Удалить».

На всякий случай после этого прилагаю тип теста:



Теперь сохраняем тест и переносим его на машину с баком.

Добавляем его в параметр «jmx» в файле load.ini и сохраняем.

Используется абсолютная адресация.

Мой выглядит так:



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

Для этого вы можете использовать инструмент pgAdmin или просто зайти на сервер с БД и посчитать строки до и после запуска скрипта.

Подключение к базе данных осуществляется аналогичной командой:

psql -h IpAddress -d dbName -U UserName

Мы считаем себя так:

select count(*) from alert;

Возвращаемся к машине с баком, переходим в директорию, где находится load.ini и вводим команду для запуска танка:

yandex-tank

Через несколько секунд после запуска появится окно с текущими параметрами теста.

Имейте в виду, что при коротких тестах танк может не успеть получить данные о текущих параметрах.

Мониторинг

К счастью, настройка мониторинга с помощью Overload требует минимальных усилий.

Достаточно следующих шагов:

• регистрация на Перегрузка ;
• получаем токен, нажав на иконку профиля в Overload и выбрав «мой API-токен»;
• создать token.txt в той же папке, что и load.ini на машине с танком;
• введите полученный токен в token.txt и сохраните его;
• добавьте блок [overload] в load.ini — описание из танкеров;

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

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

Вывод всех метрик можно организовать в Grafana. Для этого вы можете использовать процесс установки в этом гид .

Напоследок хотелось бы сказать, что с недавнего времени, а именно начиная с версии 3.2, в JMeter есть встроенное решение на базе influx для мониторинга, но там, в отличие от Overload, вам придется все настраивать самостоятельно.

Вот и все.

Всем удачной стрельбы! Теги: #jmeter #postgresql #yandex.tank #Яндекс.

Overload #нагрузочное тестирование #postgresql #Тестирование веб-сервисов

• Конференция Defcon 16. «Игры Со Штрих-Кодами». Феликс Линднер, Руководитель Recurity Labs

  19 Oct, 24

• Lenovo Выпустит Как Минимум 12 Мотомодов

  19 Oct, 24

• Ситуация С Яблочными Сообществами В России

  19 Oct, 24

• Большое Яблоко Уже Здесь?!

  19 Oct, 24

• Сварка Оптических Волокон. Часть 1: Кабели И Их Разделка, Оптические Приборы, Муфты И Кроссы, Разъемы И Переходники.

  19 Oct, 24

• Стартовали Предзаказы На Yotaphone За 20 000 Рублей.

  19 Oct, 24

• Облако Для Компаний-Разработчиков: Jelastic Как Пример Решения Из Azure Marketplace

  19 Oct, 24

• Россия Снова Стала Чемпионом Мира По Программированию

  19 Oct, 24

• Оптимизация Блога: Изящный Метод

  19 Oct, 24

• Представитель Оон Выслан Из Судана За Ведение Блога

  19 Oct, 24