Хороший способ рассчитать время выполнения SQL-запросов при использовании Linq to SQL
-
09-06-2019 - |
Вопрос
Есть ли хороший способ рассчитать время выполнения SQL-запросов при использовании Linq to SQL?Мне действительно нравится функция ведения журнала, но было бы здорово, если бы вы могли каким-то образом также засечь время выполнения этого запроса.Есть какие-нибудь идеи?
Решение
Профилировщик SQL для получения запроса и времени, а также пути выполнения в анализаторе запросов, чтобы увидеть, где находятся узкие места.
Другие советы
Как уже сказали два человека, SQL Profiler - это готовый инструмент для этого.Я не хочу быть эхом, но я хотел бы остановиться немного подробнее:Он не только предоставляет фактические тайминги с SQL Server (в отличие от таймингов со стороны приложения, где тайминги сетевого ввода-вывода, подключения и пула соединений добавляются в общий список), но также предоставляет вам [часто более важные] статистические данные ввода-вывода, информацию о блокировке (по мере необходимости) и т.д.
Причина, по которой статистика ввода-вывода важна, заключается в том, что очень дорогостоящий запрос может выполняться быстро, потребляя чрезмерное количество ресурсов сервера.Если, например, выполняемый запрос часто обращается к большим таблицам и в результате сканирования таблиц нет совпадающих индексов, затронутые таблицы будут кэшированы в памяти SQL Server (если это возможно).Иногда это может привести к тому, что один и тот же запрос будет выполняться невероятно быстро, в то время как фактически он наносит вред остальной части системы / приложения / базы данных, потребляя ресурсы сервера.
Информация о блокировке почти так же важна -> крошечные запросы, выполняющие поиск PK для одной записи, могут иметь плохие тайминги из-за блокировки.Я где-то читал, что этот самый сайт страдал от взаимоблокировок в первые дни своего бета-тестирования.SQL Profiler также является вашим другом в выявлении и устранении проблем, вызванных блокировкой.
Подводя итог этому;используете ли вы L2S, EF, plain 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
Вы могли бы использовать System.Diagnostics.Stopwatch
это позволит вам отслеживать время выполнения запроса.Просто помните, что запросы Linq-> SQL не выполняются до тех пор, пока вы не выполните над ними перечисление.Также обратите внимание, что если вы входите в Console.Out
это значительно снизит производительность.
Что вы могли бы сделать, так это добавить пользовательскую реализацию TextWriter в DataContext.Журнал, который запишет сгенерированный sql в файл или память.Затем перебирайте эти запросы, выполняя их с помощью необработанного ADO.NET кода, окружая каждый секундомером.
Я использовал подобную технику раньше, потому что казалось, что всякий раз, когда я разрабатывал какой-то код, у меня никогда не открывался профилировщик, и было действительно легко вывести эти результаты на HTML-страницу.Конечно, вы выполняете их дважды для каждого запроса веб-сайта, но полезно видеть время выполнения как можно скорее, а не ждать, пока вы поймаете что-то в Profiler.
Также, если вы перейдете к маршруту инструмента SQL, я бы порекомендовал погуглить "самый медленный запрос DMV" и получить хранимую процедуру, которая может предоставить вам статистику по самым медленным запросам в вашей БД.Не всегда легко прокручивать результаты профилировщика, чтобы найти неверные запросы.Кроме того, с правильными запросами через dmv sql 2005 вы также можете выполнять упорядочение, скажем, по сравнению с cpuвремя и так далее.
Мы используем SQL Profiler для тестирования наших запросов с помощью LLBLGen Pro.
Лучше всего записывать запросы в файл, и они используют SQL Profiler для определения времени их выполнения и настройки индексов для запросов.