My question is what can I do to determine the cause of the slowness, or what can I do to speed it up without knowing the exact cause.
I am running a simple query and it appears that the mapping back to the entities is taking taking forever. The result set is 350, which is not much data in my opinion.
IRepository repo = ObjectFactory.GetInstance<IRepository>();
var q = repo.Query<Order>(item => item.Ordereddate > DateTime.Now.AddDays(-40));
foreach (var order in q)
{
Console.WriteLine(order.TransactionNumber);
}
The profiler is telling me it is executing the query 7ms / 35257ms, I am assuming that the former is the actual response from the db and the latter is the time it takes NH to do it's magic.
35 seconds is too long. This is a simple mapping, one table, nested components, using fluent interface to do mappings. I just start up a simple console app and run the one query, the slowness is measured after the SessionFactory is initialized, there should only be one session, and I am not using a transaction.
Thanks
If your database query is returning quickly, then the problem is somewhere in the code itself. It's unlikely to be in NHibernate. Your comments imply that you are using custom user types, and it may very well be that there's something particularly inefficient in there. I am guessing you are using NHProf as your profiler? Perhaps you should use a straight .NET profiler and look at the performance of the code itself, including these custom types? Something like Ants, dotTrace or AQTime.
It is likely that you are doing something in your user types that takes a lot of time
Try disabling log4net. If it speeds things up and you still want to use it for other purposes, disable only nhibernate.
Related
I am working on a project that requires the following:
Extract the full SQL query from a specific NHibernate 3.2 session.
Perform specific actions on the query (i.e not necesserily log it)
Do not affect NHibernate in the whole system to avoid introducing performance issues
I checked several approaches, many of them already appearing on StackOverflow. Here are my options as I see now:
Manual
In the most naive and annoying solution, I can just follow the business logic and build the query myself - E.g, if the BL builds a criteria that does a restrictions on ID=5, I'd build a query with SELECT ... WHERE ID = 5. Since we have quite a complex BL, I'd really like to avoid that.
NHibernate interception
Originally, using the OnPrepareStatement seemed like the best bet. However, I soon discovered that the parameters of the query aren't logged which renders it quite useless.
Introspecting NHibernarnate’s ICriteria
When performing a query with NHibernate, we do it with an ICreteria object that contains the restrictions, the sorting and the aggregations definitions. It seems I could interspect it when a CriteriaWalker that is described here. However, it seems that it gets confused on complex queries. Also, in some cases we use NHibernate 3 new "QueryOver" syntax for which this solution doesn't help me.
Using ILoggerFactory
Since NHibernate 3, you can write custom log factories (sample). This gets the full SQL, however, it also affects the whole NHibernate system and it seems it is impossible to have a factory to apply for a specific ISession, or even ISessionFactory.
Custom NHibernate driver
I've considered writing a proxy NHibernate driver and assigning it to a specific SessionFactory (as described here). However, a friendly comment warns that it longer works in Nhibernate 3.2.
Using dynamic proxies
This code uses Castle's Dynamic proxies to inject itself inside ISession. I haven't tried running it yet with my server, but I am a bit wary of using such drastic measures. If nothing else works, however, I guess it is something to consider.
Suggestions?
Right now I am a bit stuck on choosing the best way to go with since nothing seems to be doing its job, quite right. If there are other suggestions, I'd love to hear them.
I'd use a standard or custom logging framework, and apply a custom filter to retrieve a flag from thread data (for example) in order to determine whether the session should be logged.
This way, you don't mess with NH internals at all, and as long as you don't set the flag, nothing gets logged.
This seems to be a pretty common problem: I load an NHibernate object that has a lazily loaded collection.
At some later point, I access the collection to do something.
I still have the nhibernate session open (as it's managed per view or whatever) so it does actually work but the transaction is closed so in NHprof I get 'use of implicit transactions is discouraged'.
I understand this message and since I'm using a unit of work implementation, I can fix it simply by creating a new transaction and wrapping the call to the lazy loaded collection within it.
My problem is that this doesn't feel right...
I have this great NHibernate framework that gives me nice lazy loading but I can't use it without wrapping every property access in a transaction.
I've googled this a lot, read plenty of blog posts, questions on SO, etc, but can't seem to find a complete solution.
This is what I've considered:
Turn off lazy loading. I think this is silly, it's like getting a full on sports car and then only ever driving it in eco mode. Eager loading everything would hurt performance and if I just had ids instead of references then why bother with Nhibernate at all?
Keep the transaction open longer. Transactions should not be long lived and keeping one open as long as a view is open would just be asking for trouble.
Wrap every lazy load property access in a transaction. Works but is bloaty and error prone. (i.e. if I forget to wrap an accessor then it will still work fine. Only using NHProf will tell me the problem)
Always load all the data for the properties I might need when I load the initial object. Again, this is error prone, both with loading data that you don't need (because the later call to access it has been removed at some point) or with not loading data that you do
So is there a better way?
Any help/thoughts appreciated.
I has had the same feelings when I first encountered this warning in NHProf. In web applications I think the most popular way is to have opened transaction (and unit of work) for the whole duration of request. For desktop applications managing transactions (as well as sessions) may be painful. You can use automatic transaction management frameworks (e.g. Castle) and declare with attributes service methods that should be run within transaction. With this approach you can wrap multiple operations into single transaction denending on your requirements. Also, I was using session-per-view approach with one opened session per view and manual transaction management (in this case I just ignored profiler warnings about implicit transactions).
As for your considerations: I strongly don't recommend 2) and 3). 1) and 4) are points to consider. But the general advice is: think, then try different approaches and find a solution that suits better for your particular situation.
I'm dealing with nHibernate performance problem during hydration of a collection. The nHibernate-generated query finishes in 1-3 seconds, but the hydration takes another 7-9 seconds for just 50-90 objects. There are multiple layers of joined objects being hydrated from one resultset and data doesn't overlap much to benefit from caching. Taking out nHibernate is out of the question and I'm simply figuring out how to make hydration faster.
One idea that I looking into is to split nHibernate code to use named queries and to control how objects in different layers are hydrated. I also found the use_reflection_optimizer parameter for nHibernate. While it seems great, there is barely any info on usage.
1) Is reflection optimizer enabled by default? I'm using .NET 4.0, so it seems that it should be turned on by default, but I can't find a clear answer to this.
2) If use_reflection_optimizer is not "true" by default, then how do I enable it? It doesn't work for me through web.config and I'm reading that it should be done through code or through section in config. Could someone provide an example?
3) Are there any other suggestions for speeding up hydration of my objects?
use_reflection_optimizer is enabled by default, and what it does is it generates a lot of runtime-needed reflection functionality at startup, instead when coming in contact with some objects for the first time. It makes startup longer, but it is better in the long run.
I think NHibernate translates named HQL queries to SQL even without reflection-optimizer.
Now, about the performance of that query, could you share some code? Could eager fetch / join help ?
Most of what I hear about NHibernate's lazy-loading, is that it's better to use it, than not to use it. It seems like it just makes sense to minimize database access, in an effort to reduce bottlenecks. But few things come without trade-offs, certainly it slightly limits design by forcing you to have virtual properties. But I've also noticed that some developers turn lazy-loading off on certain often-used objects.
This makes me wonder if there are some definite situations where data-access performance is hurt by using lazy-loading.
So I wonder, when and in what situations should I avoid lazy-loading one of my NHibernate-persisted objects?
Is the downside to lazy-loading merely in additional processing time, or can nhibernate lazy-loading also increase the data-access time (for instance, by making additional round-trips to the database)?
Thanks!
There are clear performance tradeoffs between eager and lazy loading objects from a database.
If you use eager loading, you suck a ton of data in a single query, which you can then cache. This is most common on application startup. You are trading memory consumption for database round trips.
If you use lazy loading, you suck a minimal amount of data in a single query, but any time you need more information related to that initial data it requires more queries to the database and database performance hits are very often the major performance bottleneck in most applications.
So, in general, you always want to retrieve exactly the data you will need for the entire "unit of work", no more, no less. In some cases, you may not know exactly what you need (because the user is working through a wizard or something similar) and in that case it probably makes sense to lazy load as you go.
If you are using an ORM and focused on adding features quickly and will come back and optimize performance later (which is extremely common and a good way to do things), having lazy loading being the default is the correct way to go. If you later find (through performance profiling/analysis) that you have one query to get an object and then N queries to get the N objects related to that original object, you can change that piece of code to use eager loading to only hit the database once instead of N+1 times (the N+1 problem is a well known downside of using lazy loading).
The usual tradeoff for lazy loading is that you make a smaller hit on the database up front, but you end up making more hits on it long-term.
Without lazy loading, you'll grab an entire object graph up front, sucking down a large chunk of data at once. This could, potentially, cause lag in your UI, and so it is often discouraged. However, if you have a common object graph (not just single object - otherwise it wouldn't matter!) that you know will be accessed frequently, and top to bottom, then it makes sense to pull it down at once.
As an example, if you're doing an order management system, you probably won't pull down all the lines of every order, or all the customer information, on a summary screen. Lazy loading prevents this from happening.
I can't think of a good example for not using it offhand, but I'm sure there are cases where you'd want to do a big load of an object graph, say, on application initialization, in order to avoid lags in processing further down the line.
The short version is this:
Development is simpler if you use lazy loading. You just traverse object relationships in a natural OO way, and you get what you need when you ask for it.
Performance is generally better if you figure out what you need before you ask for it, and ask for it in one trip to the database.
For the past few years we've been focusing on quick development times. Now that we have a solid app and userbase, we're optimizing our data access.
If you are using a webservice between the client and server handling the database access using nhibernate it might be problematic using lazy loading since the object will be serialized and sent over the webservice and subsequent usage of "objects" further down in the object relationship needs a new trip to the database server using additional webservices. In such an instance it might not be too good using lazy loading. A word of caution, be careful in what you fetch if you turn lazy loading of, its way to easy to not think this through and through and end up fetching almost the whole database...
I have seen many performance problems aring from wrong loading behaviour configuration in Hibernate. The situation is quite the same with NHibernate I think. My recommendation is to always use lazy relations and then use eager fetching statemetns in your query - like fetch joins - . This ensures you are not loading to much data and you can avoid to many SQL queries.
It is easy to make a lazy releation eager by a query. It is nearly impossible the other way round.
I am using NHibernate for ORM and have consolidated the loading of lots of entities into one big query.
I am actually loading a word dictionary, around 500K entries, and each word relates to others. Running the loading process in the background could be very tricky in our application, as we would have to manually load an entry that has not been loaded on time, as any word could be asked for at any time. Our only requirements are that all the data be loaded as fast as possible.
I also tried using a stateless session, but got an exception that stateless sessions can't fetch collections (for some reason, maybe it has to do with the fact there is no cache for stateless sessions?)
The problem is that although the query takes no more than 25 seconds in SQLServer, it takes well over 3 minutes for ICriteria.List().
I used NHProf to profile the loading process and found that the creation of the entities is a costly affair, which takes up most of the loading time in NHibernate.
Is there anything I could do to reduce this latency? Is the memory allocation expensive, or is it the "filling in" of the data?
Thanks!
Perhaps you should consider the fact that NHibernate (like most ORMs) is not particularly suited (or intended) for these types of bulk-loading scenarios. How many rows are you trying to load, give or take? What are you trying to do? Pre-populate a cache? Do batch-like processing?
My gut feeling is that you should seriously consider the purpose of your app and choose the underlying technologies accordingly. Perhaps you can shed some light on your intentions/requirements?
EDIT OK, from your comments I understand what it is you're trying to do here. The first thing I'd do is create a simple prototype using raw ADO.NET to load the same data, to get a feel for the best performance attainable using standard data access and in-memory collections. Next, fiddle around with different collection types to see what performs well when populating and searching. If loading data like this is still too slow, it's time to start looking at other methods of loading the data: file-based from a local data file, hydrating pre-serialized objects, some form of fast on-demand loading, etc.
Loading 500k entities into an NHibernate session is not a good idea. The session is made to be short lived and hold a relatively small number of entities.
If you want to do this kind of batch processing in NHibernate you should take a look at the StatelessSession instead of the ordinary session. Using a stateless session would most likely drastically improve performance in this scenario. However, when using a stateless session you lose the benefits of the NHibernate first level cache, such as change tracking.
More information about the StatelessSession can be found in this article and in the NH docs at nhibernate.info.
In this scenario I would also recommend that you consider using straight ADO.NET instead of NHibernate. I am not saying that you should switch you whole data access strategy to ADO.NET but you might want to consider using ADO.NET for the batch operations and using NHibernate for the other cases.
Profiling the creation process (for example with the VS performance analyser) should tell you exactly what is the costly operation. If you have played already with lazy loading tuning then I think the only good solution is to encapsulate the returned list to enable paging an return smaller chunks in a few iterations. I am not sure whether NHibernate support lazy result lists like JPA does (i.e. not loading entities from data reader until needed).