So far we have covered all the basic concepts of NHibernate. You have officially learnt to use NHibernate if you have followed all the previous six chapters so far. From this chapter onwards, we will talk more about "how" rather than "what". These next few chapters will concentrate on practical advice to use NHibernate in different situations. Particularly in this chapter, we will talk about optimizing your data access layer.
Though this chapter talks about optimization and mostly performance optimization (and memory optimization in some cases), do not feel inspired to go and apply these techniques/guidelines to your current project right away. Performance optimization is a relative thing. What is good performance for one project may not be good for another. Besides your use of NHibernate, performance is also driven by lot of other factors such as design of database schema, presence of proper indexes, size of the database, actual SQL queries, hardware specification of the server, kind of software the server is running, and so on. I always tell my teams that software should not be designed for performance but to meet the functional requirements and other strategic non-functional requirements such as testability, modularity, and so on. When it comes to performance, you should first baseline the performance and then optimize it. Features/techniques/guidelines discussed in this chapter are good set of knowledge to have. Read them, understand them, and think how you can use them, but do not use them without understanding the nature of the performance problem you are dealing with.
Trying to optimize any software without determining a baseline is like shooting in the dark. You may hit the target but not before you have spent significant time hitting the wrong thing. Same goes for use of NHibernate. Before you think of optimizing your data access layer, first measure how it is performing. You can use various different tools to measure performance of your data access layer. NHProfiler from www.hibernatingrhinos.com is one of the best tools that I have come across so far. Besides showing basic details such as the actual SQL sent to server and time taken to execute each SQL statement, NHProfiler shows some interesting information about your queries. I particularly like the analysis tab that groups queries by various parameters such as number of time it is run, time it took to execute, and so on.
Another feature I like is the session usage information. Following is a snapshot of the Session Usage tab giving summary of a session. It shows basic information about the session, such as how long it took to run all queries, how many entities were loaded, and so on. But it also shows alerts which is NHProfile's way of telling you how you can optimize your queries.
Once you have measured the performance, it is time to determine if there is a need to improve any aspect of the performance. It is important to understand what is fast and what is slow for your application. If you come to the conclusion that there is a genuine need to tune the performance then the first thing I would recommend you do is find out nature of read queries versus write queries in the application. The reason behind doing so is that the factors that affect the performance of read queries are different from the factors that affect write queries. For instance, an index on the database table makes read queries by indexed column faster but makes the writes into the table slower. Most of the features/guidelines discussed in this chapter apply either to read queries or to write queries but not both. Once you know the read versus write behavior in your application, it would be easy to find out where the performance lag is coming from. If it is coming from read queries (which is the case most of the times in my experience) then you know precisely how to tackle them.