Точный список шагов для базового тестирования SQL Server?

Прежде чем запускать тест производительности / базовый уровень для приложения, использующего SQL Server, я хочу иметь возможность установить экземпляр в «чистое» состояние без перезапуска экземпляра. Есть шаги, которым я склонен следовать, но я хочу создать окончательный список, который находится в правильной последовательности и не содержит лишних шагов.

Достиг ли этот список шагов установки SQL Server в «чистое» состояние?

Является ли последовательность логичной / правильной?

Есть ли лишние шаги?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Эрик Хиггинс
источник

К вашему сведению, DROPCLEANBUFFERSэто хорошо для тестирования, но не всегда точно. Если вы ссылаетесь на таблицу большого объема, очень вероятно, что у вас почти всегда будут страницы в памяти, и время ввода-вывода не будет иметь большого значения в этом запросе. Вы можете придавать IO больший вес, чем это реально в этом случае.

— JNK

Вы говорите о тестировании в производственной среде или изолированной среде тестирования?

— bopapa_1979

Любой, кто тестирует в среде Prod, должен быть уволен. :) Да, тестовые среды.

— Эрик Хиггинс

Во-первых, я отступлю и спрошу, какие измерения вы планируете собирать во время теста. Например, если вы рассчитываете логическое чтение по запросу, вам не нужно освобождать кеш. Я большой поклонник использования логических операций чтения, потому что это не зависит от того, кэшируются ли данные или на диске - и в работе трудно предположить, будут ли кэшироваться данные запроса или нет (если вы не кэшируете всю базу данных в памяти) , Если вы настроите минимизацию логического чтения, то приложение будет работать быстрее, независимо от того, находятся данные в кэше или нет.

Далее я бы спросил, что меняется между прогонами. Например, запустив EXEC SP_UPDATESTATS в каждой базе данных, как вы предложили, вы будете пересматривать статистику для таблиц, которые были обновлены. Однако, если вы не обновляете статистику с помощью fullscan, вы получаете случайные строки из таблицы - это не слишком повторяется, и я не думаю, что вы действительно хотите это делать. Вместо этого вы можете восстанавливать базы данных между каждым запуском, чтобы всегда проверять одни и те же данные. Если ваши тесты выполняют вставки / обновления / удаления, они могут иметь разные профили производительности при каждом запуске, если вы не восстанавливаете базу данных (потому что они добавляют / изменяют данные, а также меняют статистику по данным) - и даже хуже,

— Брент Озар
источник

Очень хорошие очки, цель состоит в том, чтобы все было одинаково между пробегами. Измерения, которые я делаю в этом случае @ hand, - это время выполнения для определенных функций в приложении (x секунд, чтобы вернуть список в приложение, y секунд, чтобы добавить элемент очереди и т. Д.). Изменения между тестами могут быть кусочками кода приложения, а не объектами SQL, объектами SQL и не кодом приложения, или параметрами уровня экземпляра / БД, такими как параллелизм, без изменений в коде приложения. Если бы я добавлял восстановление из шлюза перед каждым тестом, как вы относитесь к моему списку выше @ того пункта? Я что-то упустил, или последовательность требует некоторой работы?

— Эрик Хиггинс,

Брент, вы принимаете во внимание процессор в своем тестировании?

— AK

@EricHiggins Вместо того, чтобы тестировать несколько вещей одновременно, я бы тестировал их по отдельности. Я бы предпочел проверить запросы напрямую и посмотреть, какие изменения повлияют на производительность. Например, запустите трассировку SQL при выполнении определенных функций в приложении, а затем продолжайте воспроизводить эту трассировку, внося изменения в индекс / конфигурацию для повышения производительности, и наблюдайте такие вещи, как логическое чтение и показатели ЦП в трассировках.

— Брент Озар

@AlexKuznetsov Я не тот, кто проводит тестирование, на самом деле - Эрик - тот, кто задал вопрос. Когда я выполняю такую работу, я смотрю на показатели ЦП как на уровне запросов, так и на сервере в целом.

— Брент Озар

Мы используем сторонний генератор нагрузки (и у нас есть штатный сотрудник, занятый разработкой нагрузочных тестов). Так что мои тесты точны в отношении транзакции, последовательности, количества пользователей, точных шагов, выполняемых в приложении ... всего. Так что мне совсем не обязательно смотреть на метрики типа панели мониторинга SQL. Программное обеспечение для нагрузочного тестирования отслеживает время отклика модулей приложения до миллисекунды. Поэтому восстановление БД - это хорошая идея. Мне нужно проверить правильность других шагов, которые я делаю, чтобы убедиться, что я выполняю то состояние «чистого листа», которое я ищу перед каждым раундом тестирования.

— Эрик Хиггинс