Это не вопрос «который является самым быстрым ORM», и это не вопрос «как написать хороший код с ORM».Это другая сторона: код написан, запущен, несколько тысяч пользователей обращаются к приложению, но существует общая проблема с производительностью.Трассировка SQL Profiler может быть запущена только в течение короткого промежутка времени: 5 минут дают несколько сотен тысяч результатов.
Вопрос заключается в следующем: использование SQL Profiler позволяет сузить число медленных запросов (длительность большечем определенное количество времени), какие методы и решения существуют для отслеживания этих запросов SQL обратно в проблемный компонент?Напрашивается вопрос: если конкретная область медленная, как мы можем определить SQL, который она выполняет, чтобы его можно было соответствующим образом отфильтровать в SQL Profiler?
Основанием для этого является то, что у нас довольно большое приложение с довольно сложной структурой таблиц, и в настоящее время оно основано на доступе к данным через хранимые процедуры.Если возникает проблема с производительностью SQL, обычно это происходит из-за извлечения профилировщика SQL, выяснения, есть ли что-то медленное (фильтрация по длительности) или медленная область (фильтрация по хранимой процедуре), и настройка хранимых процедур (или схема - через индексацию).
Теперь есть толчок к тому, чтобы перевести наш код из решения, в основном, sproc, в решение, в основном, ORM, однако большой толчок к этому движению заключается в том, как проблемы с производительностью, если они возникают, можно отследить до проблемныхкод.Я читал вокруг, и кажется, что чаще всего это может включать сторонние инструменты (утилиты трассировки ORM, такие как NHProf или утилиты трассировки .NET, такие как dottrace), которые нам нужно было бы установить на сервер.Теперь вопрос о том, можно ли установить дополнительные инструменты в реальной среде, - это другой вопрос, поэтому, если подобные вещи можно выполнять без дополнительных инструментов, это может быть бонусом.
Меня больше всего интересуют решения с SQL Server 2008, но, вероятно, он достаточно универсален для любой СУБД.Что касается технологии ORM, то на этом я не уделяю особого внимания, так как в настоящее время ничто не используется, поэтому интересно узнать, как методы различаются (или являются общими) между nHibernate, fluent-nhibernate и Entity Framework.Другие ORM приветствуются, если они предлагают что-то еще: -)
Я прочитал Как найти и исправить проблемы с производительностью (...) , и я думаю, что проблема простораздел там, где написано «изолировать».Проблема, которую легко воспроизвести только в работающей системе, будет трудно выделить.Цифры, которые я привел в параграфе 2, представляют собой типы томов, которые мы также можем получить из профиля ...
Если у вас есть реальный опыт трассировки ORM вживую, тем лучше: -)
Обновление, 2016-10-21 : просто для полноты мы решили эту проблему для NHibernate, написав код и переопределив методы NHibernate.Полную информацию в этом другом вопросе SO я задал: NHibernate и Interceptors - измерение времени прохождения SQL-запроса .Я ожидаю, что это будет аналогичным подходом для многих различных ORM.