Назад | Перейти на главную страницу

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

Я хотел бы провести несколько тестов, чтобы сравнить наше приложение mysql в нескольких конфигурациях. Но я не хочу использовать что-то вроде тестов sysbench или oltp, потому что у нас есть сложная логика хранимых процедур. Итак ... Я хочу проверить наши процедуры.

Есть ли какое-нибудь тестовое приложение / фреймворк, который мы можем использовать для выполнения пользовательских запросов (как вариант - параллельно) и просмотра статистики? Что-то вроде Siege для Интернета? То, что я уже нашел, обычно использует собственные сгенерированные схемы и сценарии баз данных.

Я мог бы попросить своих разработчиков создать какой-нибудь пользовательский интерфейс java и использовать для него Siege, бот не хочет добавлять накладные расходы или влиять на числа.

С уважением, Игорь.

Jmeter может выполнять нагрузочное тестирование базы данных с помощью JDBC: http://jakarta.apache.org/jmeter/usermanual/build-db-test-plan.html

Раньше я не использовал функции jdbc, поэтому не знаю, сможет ли он обрабатывать ваши сложные запросы.

Мне нравится:

  1. Напишите скрипт PHP / Python / Perl для доступа к базе данных, выполнения теста и распечатки результата в формате XML.
  2. Используйте инструмент тестирования HTTP (httperf или аналогичный), чтобы загрузить базу данных и сохранить полученные результаты.
  3. Разбираем на предмет сбоев, повторяем.

Если вам нужен инструмент, который теперь поставляется вместе с MySQL 5.1, вы можете сделать хуже, чем попробовать MySQL Slap (он же mysqlslap). Пример прямо из документации:

Предоставьте свои собственные операторы SQL create и query с запросами 50 клиентов и выборками по 200 для каждого:

mysqlslap --delimiter=";" \  
--create="CREATE TABLE a (b int);INSERT INTO a VALUES (23)" \  
--query="SELECT * FROM a" --concurrency=50 --iterations=200

Это дает возможность запускать тесты параллельно, хотя реализация параллелизма с использованием нескольких клиентов может не совсем вам понравиться. Вот краткое описание (опять же дословно):

mysqlslap работает в три этапа:

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

  2. Запустите нагрузочный тест. На этом этапе может использоваться множество клиентских подключений.

  3. Очистить (отключить, сбросить таблицу, если указано). На этом этапе используется одно клиентское соединение.

Если это не совсем вам по вкусу, вы можете использовать сценарий cron для запуска MySQL Slap в определенное время для многих пользователей или для многих идентично настроенных / заданных машин с идентичными сетевыми путями к серверу и т. Д. (Последний вариант очень важно, так как сравнительный анализ должен устранить любые возможные расхождения во избежание нечетких выводов).

Если (что вполне вероятно) вы используете предыдущую версию MySQL, эта ссылка предоставляет полезную информацию о том, как скомпилировать исходный код 5.1 для 5.0; дальнейшее резервное копирование, вероятно, невозможно.

Вот базовое пошаговое руководство.

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

Мы строили что-то подобное для MS SQL в прошлом

Идея заключалась в следующем

1) Мы пишем процедуры модульного тестирования и даем им такие же префиксы имен, как «test_». В MS SQL мы также использовали расширенные свойства в качестве метаинформации для описания некоторых конкретных параметров наших тестов (так же, как в NUnit, можно использовать разные атрибуты тестов)

2) Мы пишем процедуру / скрипт, которая открывает курсор, выбирает из каталога все имена процедур, которые запускают «test_», и выполняет каждую из них в операторе EXEC (@procedure_name). Если проверка не удалась, процедура проверки должна вызвать ошибку.

3) Результаты выполнения теста хранятся в таблице.

4) Чтобы запустить тест на одних и тех же данных и получить предсказуемые результаты, у нас есть образец тестовой базы данных, которую мы резервировали один раз и восстанавливали из резервной копии перед каждым выполнением тестов.

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