Производительность LINQ и SQL Server для настройки наилучшей практики базы данных SQL Server 2008?

Question

Мой вопрос - это то, что лучше всего оптимизировать производительность, используя LINQ для SQL И производительность - это время ответа в пользовательском интерфейсе.

Сейчас у меня есть данные о продажах в базе данных SQL Server 2008, и я показываю эти данные (MAT, ежегодно, в разных сегментах, рост в сегменте, процент роста рынка ,,,,) в диаграммах в ASP .NET-приложение, использующее LINQ для SQL, для построения выражений, которые выполняются

Я вижу проблему с тем, что у меня есть база данных и я использую LINQ для построения всех вопросов, и я не могу контролировать, какой SQL создан (я могу отслеживать его, но, ,,,), и я не использую хранимые процедуры, так как мои данные извлекаются, как черный ящик.

Сейчас я бегу несколько модульных тестов и вручную протестировать приложение и использовать Databasse Engine Tuning Advisor, какие индексы и т.д., чтобы создать ....

Answer 1

Профилирование, профилирование, профилирование. :)

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

Как вы говорите, L2S может быть черным ящиком, поэтому вам нужно попытаться воспроизвести все сценарии и/или профиль, пока приложение используется реальными пользователями. Затем используйте это для 1) tweak queries 2) добавьте индексы 3) внесите любые другие изменения, необходимые для получения требуемой производительности.

У меня есть инструмент для профилирования, сделанный специально для Linq-to-SQL, чтобы сделать его немного «менее черным ящиком» - он позволяет выполнять профилирование во время выполнения, связывая сгенерированные запросы с кодом (стек вызовов) в конкретном запросе, выполняемом. Вы можете скачать и получить бесплатную пробную лицензию на http://www.huagati.com/L2SProfiler/

Фоновой причина моего профилировщика изложена в немного более подробно здесь: http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html

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

---

Другое дело, что может помочь, если у вас есть много таблиц с большим количеством столбцов, чтобы получить индекс информации в редакторе кода.Это делается путем добавления xml doc-комментариев с этой информацией к классам сущностей и свойствам-членам; что информация будет отображаться в подсказках в редакторе коды в VS:

... таким образом вы можете увидеть уже при вводе запросов, если есть индекс покрытия столбца (ы), используемый в которых положение и т.д. Чтобы не набирать все это, я создал для этого инструмент. См. «Обновление документации» в http://www.huagati.com/dbmltools/

Answer 2

В дополнение к этому, я обычно использую как SQL Profiler и Профилировщик CLR с некоторыми имитируемыми пользователями в наборе данных большого объема и отслеживать длительные запросы и/или длительные вызовы через datacontext (что может означать многократные поездки, совершаемые под обложками). Мое личное предпочтение также заключается в том, чтобы отключить отложенную загрузку и отслеживание объектов по всем моим данным datacontexts по умолчанию, поэтому в большинстве случаев мне приходится выбирать IN-множественные обратные поездки. Хотя вы не можете напрямую влиять на созданный SQL, вы можете быть осторожны с LoadWith/AssociateWith и убедиться, что вы не получаете ужасно большие/неэффективные наборы результатов и разбиваете запросы, у которых есть много дорогостоящих объединений (иногда несколько раундов -Трейпы дешевле, чем мондо на больших столах).

Все дело в измерении - используйте любые инструменты, с которыми вы можете справиться.