Also, curiously the problem doesn't appear if an equivalent query is executed through NHibernate as a raw SQL or a HQL query.
-Lauri On Friday, December 12, 2014 5:46:51 PM UTC+2, Lauri Kotilainen wrote: > > New evidence! > > We've got a new repro of a similar (albeit not identical) case, and I've > had the opportunity to dig in deeper and get better data. So far it looks > like the problem is actually inside ADO.NET -- the SqlDataReader is > waiting in COM code -- on an unmanaged lock -- and the wait times out even > though the server does send a response. However, executing the same query > using raw ADO.NET code (even using a SqlConnection created by the > NHibernate session!) still returns almost instantly, so the best hypothesis > I've come up with is that NHibernate configures the command or the reader > in a way that triggers the problem. I'll try to investigate further on > Monday if the problem still persists and if I manage to set up both .NET > and NHibernate debugging symbols. > > -Lauri > > On Monday, October 20, 2014 1:05:08 PM UTC+3, Lauri Kotilainen wrote: >> >> >> >> On Friday, October 10, 2014 7:33:57 AM UTC+3, Darren Kopp wrote: >>> >>> I would guess that the performance you see on your machine is the same >>> as on Azure, but you're likely hitting your cpu limits. I'm not sure >>> ordering would have any issue on hydration, unless perhaps you have a poor >>> hash code algorithm and perhaps were hitting worst case scenarios on hash >>> tables, but that also seems pretty suspect. Do you have any .net profiling >>> data comparing the two scenarios you outlined? >>> >> >> I did, but I didn't save it -- and guess what, by the end of the day, the >> probelm disappeared by itself. >> >> The hot spots found by the profiler were all somewhere in NHibernate's >> proxy generation code paths, which seemed extremely weird to me. >> >> I'm not sure how to interpret your comment on CPU limits. Maybe I wasn't >> very clear in my original post: running the query on the same computer (my >> dev machine) produced wildly different results with the same code, >> depending on which database I was hitting -- even though my local database >> was a very recent (minutes old) copy of the production DB, so the data sets >> were nearly identical. And removing the OrderBy eliminated the difference. >> >> I'll get back to this issue if it reappears and I manage to gather some >> more diagnostic data. >> >> -Lauri >> > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
