NHibernate performance issues #4: slow query compilation - named queries

NHibernate provides many approaches how to query the database:

• HQL (Hibernate Query Language)
• Criteria Query API
• Linq
• Native SQL

First three of these querying methods define the body of query in the other than native SQL. It implies that NHibernate must transform these queries into native SQL - according to given dialect, e.g. into native MS SQL query.

If you really want to develop all-times fast application the described process can present unpleasant behavior. How to avoid query compilation?

Compiled named queries

Its ridiculous but everyone met compiled (and named) query. If you have at least once browsed the log which NHibernate produced, you have had to meet similar set of lines:

2010-12-13 21:26:42,056 DEBUG [7] NHibernate.Loader.Entity.AbstractEntityLoader .ctor:0 Static select for entity eu.podval.NHibernatePerformanceIssues.Model.Library: SELECT library0_.Id as Id1_0_, library0_.version as version1_0_, library0_.Address as Address1_0_, library0_.Director as Director1_0_, library0_.Name as Name1_0_ FROM [Library] library0_ WHERE library0_.Id=?

When NHibernate starts (SessionFactory as spring.net bean in my case) he complies certainly usable queries. In displayed case, NHibernate knows that he'll probably search library entity in database by it's id so he'll generate native SQL query into internal cache and if the developer's code call Find for Library entity, he'll use exactly this pre-compiled select query in native SQL.

What's the main benefit? If you would call thousand times library's Find NHibernate would always has to compile the query. Instead of this inefficient behavior, NHibernate does it only once and uses pre-compiled version later.

How to speed you query? Use pre-complied named queries

As I've already written, NHibernate generates pre-compiled queries, stores them in the cache and uses them if necessary. NHibernate is the great framework, so he makes available such functionality even for you :-)

Simply you can declare list of HQL (or SQL) named queries within any mapping (hbm.xml) file, NHibernate loads the file, parse queries and preserves the pre-compiled version in his internal cache so called queries in runtime not have to be intricately parsed to native SQL, but he'll use already prepared ones.

How to use named queries?

1. Define new hbm.xml file which will include your named queries, e.g. named-queries.hbm.xml
2. Place this file within such assembly which NHibernate searches for hbm mapping files. Maybe you should have to update you Fluent NHibernate configuration to search for these files. Following code will do it for you or see FluentNHibernateSessionFactory.

m.HbmMappings.AddFromAssembly(Assembly.Load(assemblyName));

Now, it's time to write your named-queries.hbm.xml file. It has the following structure.

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

  <query name="Book.with.any.Rental">
    <![CDATA[
    select b from Book b
      where exists elements(b.Rentals)
    ]]>
  </query>

</hibernate-mapping>

How to use it?

IList<Book> books = SessionFactory.GetCurrentSession().GetNamedQuery("Book.with.any.Rental").List<Book>();

How is the speed up of named queries?

Lets say, I'll use Book.with.any.Rental query for any measures to we'll see how omitted query compilation improves test response.

I've executed the test for both named query and plain HQL. According to debug labels, plain HQL case spent 40ms by parsing of HQL to native SQL.

Note that all written till now applies only to the first call. NHibernate is tricky framework so he caches queries for you automatically when he compiles them for first time. Lets call method to get books with any rental two times (first level cache is cleared among the calls):

• first call took 190ms
• second one only 26ms 

It's also necessary to admit that database has also own query cache :-) The result is clear anyway.

What are real advantages of named queries?

It doesn't seem such brilliant think to moil with writing the queries in xml file. What are real benefits?

1. Speed (of the first call) - described example save 40ms of method call. It doesn't seem so much. Imagine that you are developing huge project having almost hundred queries. It can save a lot of time! You should also notice that chosen query was very simple. According to my experiences, the compilation of more complicated query takes at least 200ms. It's not small amount of time when you develop very quick application
2. HQL parse for error on startup - you'll find out that your query is correct or wrong at application's startup because NHibernate do these things when he starts. You haven't wait till the call of desired query
3. Clean code - you aren't mixing C# code together SQL (HQL) code
4. Possibility to change query code after the application compilation - consider that you can change your HQL or SQL even if application was already compiled. You can simply expose named query hbm.xml file as ordinary xml file and you can tune your queries at runtime - means without additional compilation

You can also see Series of .NET NHibernate performance issues to read all series articles.

Read More

NHibernate performance issues #3: slow inserts (stateless session)

The whole series of NHibernate performance issues isn't about simple use-cases. If you develop small app, such as simple website, you don't need to care about performance. But if you design and develop huge application and once you have decided to use NHibernate you'll solve various sort of issue. For today the use-case is obvious: how to insert many entities into the database as fast as possible?

Why I'm taking about previous stuff? The are a lot of articles how the original NHibernate's purpose isn't to support batch operations, like inserts. Once you have decided to NHibernate, you have to solve this issue.

Slow insertion
The basic way how to insert mapped entity into database is:

SessionFactory.GetCurrentSession().Save(object);

But what happen when I try to insert many entities? Lets say, I want to persist

• 1000 libraries
• each library has 100 books = 100k of books
• each book has 5 rentals - there are 500k of rentals 

It's really slow! The insertion took exactly 276 seconds! What's the problem?

Each SQL insert is sent to server within own server request.

Batch processing with using adonet.batch_size
You can set property adonet.batch_size within your hibernate configuration to tell NHibernate that he can sent more queries to the SQL server within one statement. I'm going to set this value to 100. What's the improvement? Insertion took 171 seconds right now. Better than 276! But isn't it a lot of time? Yes it is!

The major problem is that NHibernate standard insertion via Session.Save is not intended to use for batch processing. NHibernate generated events, go through mapping, doesn't group insert statements together in proper way by default. Obviously, it must take some time. Now, it's the time to introduce ...

Stateless session
NHibernate's developers are smart guys so this significant functionality can't stay in "not-intended for batch processing" state. Stateless session is tool intended for batch processing.

Stateless session is lightweight version of Session.Save method, it doesn't throw so much events, it's fast, it just generates one insert for given object according to mapping. It's fast, so it apparently has any drawbacks.

Stateless session's drawbacks

• stateless session isn't compatible with standard NHibernate session! There is another interface because it has completely different purpose. Spring.net's support is missing, you can't use transaction template. You must handl all the stuff by yourself.
• because of intended fast behavior, stateless session doesn't handle any cascade operation on children. You must manually push all objects to session, all children, their children, etc.

The last point seems to be very unpleasant drawback but if you look at previous picture showing NHibernate profiler you can see the major benefit of this approach.

Despite I've set adonet.batch_size to 100,  only 5 inserts are sent to SQL server within one statement. NHibernate groups inserts only for same type of entity. You aren't able to achieve optimized query count with using standard way.

As I've said, you must call Insert method for each entity, so you can group all inserts of each specific entity by your code. Here are results of insertion:

• 149 seconds - no advanced grouping when inserts are sent to sql server - insertion of first library followed by  insertion of it's books, insertion of all book's rentals, insertion of another library - we aren't still use fully utilized power of adonet.batch_size because only 5 inserts are sent in one statement

foreach (Library library in libraries) {
  session.Insert(library);
  foreach (Book book in library.Books) {
    session.Insert(book);
    foreach (Rental rental in book.Rentals) {
      session.Insert(rental);
    }
  }
}

• 86 seconds - first of all libraries are processed by session's insert following by all books and all rentals - this approach efficiently uses batch size, because for 100k of books it sents only 1000 statements to SQL server, each having 100 of insert followed by set of 5k of inserts statements for rentals

foreach (Library library in libraries) {
  session.Insert(library);    
}

foreach (Library library in libraries) {
  foreach (Book book in library.Books) {
      session.Insert(book);
  }
}

foreach (Library library in libraries) {
  foreach (Book book in library.Books) {
    foreach (Rental rental in book.Rentals) {
        session.Insert(rental);
    }
  }
}

• 80 seconds - adonet.batch_size = 1000

Stateless session is efficient!
The best result is the small summary of measured times because the main benefit of stateless session will exactly appear. The example persists (1k + 100k + 500k) 601k of entities.

session type	adonet.batch_size	additional groupping	time [s]
standard	no	no	276
standard	100	no	171
stateless session	100	no	149
stateless session	100	yes	86
stateless session	1000	yes	80

If you need to improve your application's insertion time, just use stateless session.

You can also see Series of .NET NHibernate performance issues to read all series articles.

Read More