Хороший путь к SQL-запросам времени при использовании Linq для SQL

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

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

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

Блокировка информации почти как важная->, крошечные запросы, делающие поиски PK для единственной записи, могут иметь плохие синхронизации из-за блокировки и блокирования. Я считал где-нибудь, что этот самый сайт был заполонен мертвыми блокировками в ранние бета дни it. 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

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

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

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

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

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