Тестирование масштабируемости хранимых процедур


14

У меня есть приложение электронной почты, которое будет вызываться для доставки в пользовательский интерфейс количества новых сообщений для данного пользователя при каждой загрузке страницы. У меня есть несколько вариантов вещей, которые я тестирую на уровне БД, но все они абстрагированы хранимым вызовом proc.

Я пытаюсь захлопнуть БД, чтобы увидеть, какой будет точка разрыва (количество запросов в секунду).

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

Как сделать этот тест хорошим для достижения результатов теста на основе производительности SQL?

Есть ли инструмент для этого, чтобы я мог дать ему имя сохраненного процесса и параметр, чтобы он мог использовать мою БД?

Я хочу посмотреть, может ли БД вернуть мин. 250 ответов в секунду.


1
Отличный вопрос Я бы расширил его до более общего характера и спросил: как вы тестируете свою базу данных?
Ник Чаммас

Ответы:


11

SQLQueryStress - отличный инструмент для небольшого параллельного тестирования, но он не совсем подходит для нагрузочного тестирования. Удивительно малоизвестный набор инструментов доступен бесплатно от Microsoft, который может справиться с большинством сценариев стресс-тестирования SQL Server, утилитами RML .

Очень краткий обзор инструментов:

  • ReadTrace преобразует трассировки Profiler из файлов .trc в .rml (язык разметки воспроизведения).
  • OStress используется для воспроизведения файлов .rml и .sql на сервере.
  • ORCA (агент управления воспроизведением OStress) координирует воспроизведение между распределенными экземплярами OStress.
  • Reporter предоставляет отчеты об анализе производительности.

Существует отличная статья по быстрому старту от команды SQLCat, которая включает образец базы данных и рабочие нагрузки, Precision Performance для Microsoft SQL Server с использованием RML Utilities 9.0

У вас есть возможность либо выполнить профилирование для воспроизведения, либо, возможно, более уместно в вашем сценарии, вручную запустить набор сценариев .sql, которые вы затем воспроизводите с помощью OStress и ORCA.

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


6

Одним из инструментов, который вы можете использовать, является SQLQueryStress . Для быстрого начала укажите: хранимую процедуру, количество итераций и количество потоков. Затем начните стресс-тестирование. Будут показаны такие метрики, как секунды процессора, логическое чтение и т. Д.


4

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

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

Вот так я и поступил бы.


Почему бы вам не написать это приложение, используя мой проект с открытым исходным кодом Benchmark.NET и используя параллельный тест?
Андрей Ринея
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.