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

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

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

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

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

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

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

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.

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

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

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

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

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