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

Question

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

Answer 1

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

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

Информация о блокировке почти так же важна -> крошечные запросы, выполняющие поиск по 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 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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