Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 10 | Comments: 37

filter by tags archive

NHProf new feature: Expensive queries report

time to read 1 min | 105 words

It has been a while since we had a new major feature for the profiler, but here it is:


The expensive queries report will look at all your queries and surface the most expensive ones across all the sessions. This can give you a good indication on where you need to optimize things.

Naturally, this feature is available across all the profiler profiles (NHibernate Profiler, Entity Framework Profiler, Linq to SQL Profiler and Hibernate Profiler).



What is the definition of expensive query? Long execution time? CPU utilization? IO utilization? Heavy locking?

Also, the total cost of query (TCQ for CIOs) is calculated by multiplying single query cost by number of query executions / unit of time

Ayende Rahien

Expensive means took the longest time.

This is calculated on a single query basis, not across all similar queries.

Gian Maria Ricci

This tend to be a really really nice feature, but I think that query optimization is best done using a profiler in production environment and finding what is happening during real database usage and in real production machine.

Execution time tends to be different from local sql server, or dev machine respect to production one, but surely this is a nice feature to have.

NHProfiler really rocks.


Ayende Rahien


I agree with you that only on production (or at least QA) you can find the real numbers.

But even on non prod systems, that can give you very strong indications about how things are going

Gian Maria

Yes, you are right, in dev environment we can have indicators, just to find if some queries are really really bad, and then refinement should be made on QA or Production machine.

In my opinion the problem is in the hardware: some devs have machine with 2 gb ram and they test on local sql server, but numbers are really really different when you run the same set of queries on a 2xXeon, 12 GB ram and a bunch of SAS 15k iSCSI disks :).


Comment preview

Comments have been closed on this topic.


  1. Production postmortem: The case of the memory eater and high load - 7 hours from now
  2. Production postmortem: The case of the lying configuration file - about one day from now
  3. Production postmortem: The industry at large - 2 days from now
  4. The insidious cost of allocations - 3 days from now
  5. Find the bug: The concurrent memory buster - 4 days from now

And 4 more posts are pending...

There are posts all the way to Sep 10, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    14 Aug 2015 - The case of the man in the middle
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats