Хороший способ времени SQL-запросы при использовании Linq to SQL

Question

Есть ли хороший способ времени SQL-запросов при использовании Linq to SQL? Мне очень нравится функция ведения журнала, но было бы здорово, если бы вы могли как-то также запросить время. Есть идеи?

Answer 1

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

Answer 2

Мы используем SQL Profiler для тестирования наших запросов с помощью LLBLGen Pro.

Answer 3

Вы можете использовать System.Diagnostics.Stopwatch, что позволит вам отслеживать время выполнения запроса. Просто помните, что запросы Linq-> SQL не выполняются, пока вы не перечислите их. Также обратите внимание, что если вы регистрируетесь до Console.Out, будет значительный удар по производительности.

Answer 4

Лучше всего регистрировать запросы к файлу, и они используют SQL Profiler для их времени и настройки индексов для запросов.

Answer 5

Как уже говорили два человека, SQL Profiler - это готовый для использования инструмент. Я не хочу быть эхом, но я хотел бы подробнее остановиться на деталях: он не только обеспечивает фактические тайминги с SQL Server (в отличие от времени со стороны приложения, где сетевой вход, подключение и подключение а также дает вам [часто более важные] статистические данные ввода/вывода, информацию о блокировке (по мере необходимости) и т. д.

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

Информация о блокировке почти так же важна - крошечные запросы, выполняющие поиск PK для одной записи, могут иметь плохие тайминги из-за блокировки и блокировки. Я где-то читал, что этот сайт был забит тупиками в его ранних бета-версиях. SQL Profiler - ваш друг для определения и устранения проблем, вызванных блокировкой.

Подводя итог; используете ли вы L2S, EF, обычный ADO - если вы хотите убедиться, что ваше приложение «ведет себя хорошо» к базе данных, всегда имеет SQL Profiler, готовый во время разработки и тестирования. Он окупается!

Редактировать: Поскольку я написал ответ выше, я разработал новый инструмент профилирования времени исполнения для L2S, который объединяет лучшее из обоих миров; Статистика ввода-вывода и временные интервалы на стороне сервера из SQL Server, план выполнения SQL Server, предупреждения «отсутствующих индексов» SQL Server в сочетании с стеком управляемых вызовов, чтобы упростить поиск кода, генерирующего определенный запрос, и некоторые дополнительные параметры фильтра для регистрации только запросов, которые соответствуют определенным критериям. Кроме того, компонент протоколирования может быть распространен с приложениями, чтобы упростить выполнение профилей запросов во время работы в среде с живыми клиентами. Инструмент можно скачать с:

http://www.huagati.com/L2SProfiler/, где вы также можете получить бесплатную пробную лицензию на 45 дней.

Более длинное описание фона и интро к инструменту также размещен здесь:
http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html

... и образец/пошаговое руководство использования некоторых из более продвинутых вариантов фильтров можно найти здесь:
http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html

Answer 6

Что вы можете сделать, это добавить пользовательскую реализацию TextWriter в DataContext.Log, который будет записывать сгенерированный sql в файл или память. Затем пропустите эти запросы, выполнив их с необработанным кодом ADO.NET, окружая каждый секундомер.

Я использовал подобную технику раньше, потому что, казалось, всякий раз, когда я разрабатывал какой-то код, у меня никогда не было открытого профиля Profiler, и было очень легко выводить эти результаты на HTML-страницу. Уверенный, что вы выполняете их дважды в каждом запросе веб-сайта, но полезно видеть время выполнения как можно скорее, а не ждать, пока вы не поймаете что-то в Profiler.

Также, если вы перейдете на маршрут SQL Tool, я бы рекомендовал googling «самый медленный запрос DMV» и получить хранимую процедуру, которая может дать вам статистику по самым медленным запросам в вашем db. Не всегда легко прокручивать результаты профилировщика, чтобы найти плохие запросы. Также с правильными запросами по dmv sql 2005 вы также можете упорядочивать, давайте скажем cpu против времени и так далее.