Как тестировать решения правильно(чтобы один и тот же запрос выполнялся за одно и то же время)

Приветствую!

Есть проблема на работе: БД находится на сервере. С ней работают другие программисты(напрямую запросами) и простые пользователи(через приложение для получения данных). Я часто тестирую различные варианты запросов и огромная проблема состоит в том, что один и тот же запрос может выполняться за сильно разное время (например от 1 до 7ми секунд или от 11 до 25). Разумеется, принять правильное решение о преимуществах или недостатках тестируемого метода просто невозможно — фактор ложноположительных и ложноотрицательных результатов не даёт.

Вопрос: как проводить тесты "вчистую"?
Что для этого нужно сделать? Какие шаги нужно для этого предпринять?

0

Сообщение от Jack Famous С ней работают другие программисты(напрямую запросами) и простые пользователи(через приложение для получения данных).

т.е. программисты работают на "живой" базе параллельно с пользователями? Смелые Вы люди, нифига не боитесь: одно неловкое движение - и база умерла, поднимать ее потом из бэкапа (если он есть, конечно) - та еще веселуха...

0

D1973, не всё так плохо) Работаю на копии рабочей базы, но всё-равно, на том же сервере.

0

Сообщение от Jack Famous один и тот же запрос может выполняться за сильно разное время

Надеюсь читали (рассмотрены почти все варианты):

Медленно в приложении, быстро в SSMS (часть 1) и далее часть 2, часть 3.

1

Сообщение от PaulWist Надеюсь читали (рассмотрены почти все варианты):

там много. Я прочту, но позже.
Подскажите, если не сложно, как это относится к моей проблеме.
Тестирую запросы в одном и том же окне(query) SSMS с разницей в секунды. Время выдаётся иногда одинаковое, а иногда сильно разное. Я подозреваю, что это исключительно нагрузка на сервер карты путает и хочу от этого уйти.
Время запросов меняется даже у относительно простых, планы запросов не меняются.

0

Сообщение от Jack Famous Я часто тестирую различные варианты запросов и огромная проблема состоит в том, что один и тот же запрос может выполняться за сильно разное время (например от 1 до 7ми секунд или от 11 до 25).

Чаще всего так случается по двум причинам:
1. Локи.
Если вы тестируетесь на отдельной базе, а работа ведется на базе с большим количеством параллельных подключений, чаще всего это связано с тем, что ваш запрос простаивает в ожидания снятия лока параллельного процесса.
Нужно очень пристально следить за индексами и статистиками.
2. Использование tempdb при работе запроса, для сохранения промежуточных результатов.
Тут может быть как вариант коряво написанного запроса, для которого энжин не смог правильно оценить кардинальность, не смог правильно построить план, и не смог правильно выделить память на исполнение, и, соответственно, в процессе выполнения вынужден вывалить промежуточные данные на диск, так и тот вариант, когда ваши данные в принципе в память и не поместятся, и в любом случае нужно будет использовать tempdb, или, к примеру, поднимать данные с диска.
Внешне, если использовать инструментарий по анализу того "че там собственно творится внутри" - это будет выглядеть одинаково.
Запрос хаотически тормозит. То за доли секунды выполняется, то минутами висит.

PaulWist, думаю, ТС не об этом.
В "Медленно в приложении, быстро в SSMS", большей частью про другое. Один и тот же запрос работает по-разному, в зависимости от каких-то настроек. В одном случае - стабильно быстро, в другом - стабильно медленно.

1

Сообщение от Jack Famous как это относится к моей проблеме.

Например, (классика жанра) - запуск запроса с разными параметрами/значениями.

Есть табличка T имеющая 10 записей в индесированном поле F, из них 9 записей = "А" и одна запись = "Б", запрос

Сервер видит, что таких записей 9 шт, и выбирает сканирование таблички.

Теперь

Сервер видит, что таких записей 1 шт, и выбирает поиск по индексу.

Если планы не меняются, то посмотрите на количество возвращаемых результатов, может там 1.5Г возвращается.

А вообще uaggster направление поиска дал, но тут пальцем в небо

0

Сообщение от PaulWist Если планы не меняются, то посмотрите на количество возвращаемых результатов, может там 1.5Г возвращается.

Такую штуку удобно с set statistics io on смотреть. Да и в целом оно удобнее, чем просто время засекать. Выдает стабильный результат для сравнения вне зависимости от прогретости кэша и локов

1

uaggster, данные не свопятся, используются #таблицы и CTE.
Я думаю, что нужно на локали тестить, а не на сервере. Что думаете?

Сообщение от PaulWist Если планы не меняются, то посмотрите на количество возвращаемых результатов, может там 1.5Г возвращается.

время отсекается по вставке во временную таблицу, потому что Select размывает время теста во времени вывода данных с сервера. Запрос один и тот же. Пул данных, соответственно, тоже одинаковый: 1,5 млн записей.

Сообщение от katamoto Выдает стабильный результат для сравнения вне зависимости от прогретости кэша и локов

вы IO с Time перепутали, наверное. В Time не учитывается время простоя?

0

Сообщение от Jack Famous вы IO с Time перепутали, наверное. В Time не учитывается время простоя?

Нет, не перепутал. Я про количество логический чтений говорил

0

Сообщение от Jack Famous Что для этого нужно сделать?

Смотреть CPU time запроса

1

Сообщение от katamoto Нет, не перепутал. Я про количество логический чтений говорил

как это связано со временем работы? Вы читали шапку темы?
Ну, то есть, количество чтений связано, конечно, но сможете ли вы сказать по тексту IO 2ух запросов, какой лучше работает? Тест ведь, может быть очень большим, как и запрос …

Сообщение от invm Смотреть CPU time запроса

прошу продемонстрировать

0

Сообщение от Jack Famous прошу продемонстрировать

Что продемонстрировать?

0

invm, простите — тупанул
Это при Set Statistics Time On выводится.
Спасибо!

0

Jack Famous, плюс исключить вывод результирующих наборов

0

invm, можно подробнее, пожалуйста? Я не в курсе, что это …
И, чтобы, закрепить, я правильно понимаю, что CPU-Time не учитывает время ожидания и прочего мусора?

P.S.: прочёл, что CPU-Time может быть больше фактического из-за того, что складываются времена каждого участвующего ядра (параллелизм). Но для сравнения "при прочих равных" это не важно.

0

Сообщение от Jack Famous как это связано со временем работы? Вы читали шапку темы? Ну, то есть, количество чтений связано, конечно, но сможете ли вы сказать по тексту IO 2ух запросов, какой лучше работает? Тест ведь, может быть очень большим, как и запрос …

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

0

Сообщение от Jack Famous Я не в курсе, что это …

Это про что?

Сообщение от Jack Famous я правильно понимаю, что CPU-Time не учитывает время ожидания и прочего мусора?

Да.

1

Пересмотрите БД в плане используемых индексов, по возможности замените rowstore индексы на columnstore.

0

andrey197888888, какое это имеет отношение к теме тестирования?
Вы решили сразу в нескольких темах отметиться?

Добавлено через 6 минут

Сообщение от invm Это про что?

Про наборы.

Сообщение от invm плюс исключить вывод результирующих наборов

Сообщение от Jack Famous invm, можно подробнее, пожалуйста? Я не в курсе, что это …

0