December 12, 2011 at 1:48 am
For amusement when reading another topic (http://michaeljswart.com/2011/12/cxpacket-whats-that-and-whats-next/) I decided to run that against my DB that gets hit by the nHibernate queries.
In short the above post gives an example to show the top 20 worst hit parallel queries.
The result I got was 20 variations on a theme of the same query. I expanded it to 100 and I'd say 90 of them were the same query. Whilst it definitely confirms that it's a pretty poor query, it highlights the problem with diagnosing statements that can and should be refined. I'm sure I get hit with a lot more queries, but to separate these out to something useful ? My top 100 isn't really a top 100 then. It's a top 10 or 11. It is possible to get this same sort of problem whatever you look at.
Something worth looking at when you get this is the execution plan and the sheer number of 'compute scalar' icons in the execution plan. They will be very easy to spot (albeit with 0% cost)
January 31, 2012 at 5:39 am
Thanks David, great article - 5 stars!
Our Devs here are using nHibernate for a new project so I'll be keeping an eye on this.
I agreed to it with the proviso that I am not responsible for performance issues caused by it but lets see how long that lasts if it all goes south!
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply