Отслеживание производительности ORM

Это не вопрос «какая самая быстрая ORM» и не вопрос «как писать хорошо» код с ORM ". Это другая сторона: код написан, он запущен, несколько тысяч пользователей работают с приложением, но есть предполагаемая общая проблема с производительностью. Трассировку SQL Profiler можно запустить только в течение короткого промежутка времени: 5 минут дают несколько сотен тысяч результатов.

Вопрос прост: использование SQL Profiler для сужения количества медленных запросов (продолжительность больше заданной количество времени), Какие существуют методы и решения для отслеживания этих SQL-запросов до проблемного компонента? Возникает вопрос: если определенная область работает медленно, как мы можем определить SQL, который выполняет эта область, чтобы его можно было соответствующим образом отфильтровать в SQL Profiler?

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

Теперь есть толчок к тому, чтобы переместить наш код из решения, в основном использующего sproc, в решение, в основном использующее ORM, однако большой толчок к этому шагу заключается в том, как проблемы с производительностью, если они возникают, могут быть связаны с проблемным кодом. Я читал, и кажется, что чаще всего это может включать сторонние инструменты (утилиты трассировки ORM, такие как NHProf или утилиты трассировки .NET, такие как dottrace), которые нам необходимо установить на сервере. Теперь другой вопрос, можно ли установить дополнительные инструменты в живую среду, поэтому, если такие вещи можно выполнять без дополнительных инструментов, это может быть бонусом.

Меня больше всего интересуют решения с SQL Server 2008, но, вероятно, он достаточно универсален для любой СУБД. Что касается технологии ORM, у меня нет особого внимания, так как в настоящее время ничего не используется, поэтому мне интересно узнать, чем отличаются (или распространены) методы twixt nHibernate, fluent-nhibernate и Entity Framework. Однако приветствуются другие ORM, если они предлагают что-то еще: -)

Я прочитал Как найти и исправить проблемы с производительностью (...) , и я думаю, что проблема просто в разделе о там написано "изолировать". Проблема, которую легко воспроизвести только на живой системе, будет трудно изолировать. Цифры, которые я привел в параграфе 2, - это цифры типов томов, которые мы также можем получить из профиля ...

Если у вас есть реальный опыт трассировки ORM в реальном времени, тем лучше :-)

Обновление, 21.10.2016 : Для полноты картины мы в конечном итоге решили эту проблему для NHibernate, написав код и переопределив методы NHibernate. Полная информация в этом другом вопросе SO, который я задал: NHibernate и перехватчики - измерение времени приема-передачи SQL . Я ожидаю, что это будет аналогичный подход для многих различных ORM.