Как лучше всего измерить производительность запроса?


19

У меня есть 2 хранимые процедуры, где вторая хранимая процедура является улучшением первой.

Я пытаюсь точно определить, насколько это улучшение.

1 / Измерение clock timeне представляется возможным, поскольку я получаю разное время выполнения. Хуже того, иногда (редко, но бывает) время выполнения второй хранимой процедуры больше, чем время выполнения первой процедуры (я полагаю, из-за нагрузки сервера в этот момент).

2 / Include client statisticsтакже дает разные результаты.

3 / DBCC DROPCLEANBUFFERS, DBCC FREEPROCCACHEэто хорошо, но та же история ...

4 / SET STATISTICS IO ONможет быть вариантом, но как я могу получить общий балл, так как в моих хранимых процедурах задействовано много таблиц?

5 / также Include actual execution planможет быть вариантом. Я получаю estimated subtreecost0,3253 для первой хранимой процедуры и 0,3079 для второй. Можно ли сказать, что вторая хранимая процедура быстрее на 6% (= 0,3253 / 0,3079)?

6 / Использование поля «Чтения» из SQL Server Profiler?

Итак, как я могу сказать, что вторая хранимая процедура на x% быстрее, чем первая процедура, независимо от условий выполнения (рабочей нагрузки сервера, сервера, на котором выполняются эти хранимые процедуры и т. Д.)?

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

Ответы:


17

Мне нравится использовать бесплатный инструмент SQLQueryStress при сравнении сценариев до и после. С SQLQueryStress вы можете выполнять каждую хранимую процедуру столько раз, сколько захотите, и получать общую среднюю статистику для всех выполнений.

Например, вы можете выполнить каждую хранимую процедуру 100 раз, а затем использовать статистику для резервного копирования ваших улучшений. «Более 100 выполнений, мои улучшения экономят в общей сложности 30 секунд, а сохраненный процесс выполняет на 1500 операций меньше чтения за выполнение». Я думаю, вы поняли идею.

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

Документация по SQLQueryStress: http://www.datamanipulation.net/sqlquerystress/documentation/documentation.asp

SQLQueryStress


6

4 / Вы можете перейти по адресу http://statisticsioparser.com/statisticsioparser/ и вставить свою статистику, чтобы увидеть общий счет.


Логические чтения: 3101 против 2943. Чтения в режиме чтения: 0 против 8. Количество сканирований: всего 637. Физические чтения: 0 в целом. LOB Logical Читает: 156 всего.
Михай Беженариу,

3

Когда вы соберете время выполнения для двух хранимых процедур за пару дней, я рекомендую вам использовать эту домашнюю страницу

http://www.evanmiller.org/ab-testing/t-test.html

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

Разница в 6% не так много, когда речь идет об улучшении хранимых процедур. Я пришел, чтобы ожидать от моего коллеги двух порядков, и я притворяюсь разочарованным, если он достигнет только одного порядка ...

Ему не нужно использовать домашнюю страницу EvanMiller, чтобы доказать, что его решение работает быстрее.

Я также установил бы SQLSentrys (edit :) Plan Explorer с http://www.sqlsentry.com/, так как это значительно улучшенный инструмент для сравнения планов выполнения.

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