Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Challenges: Where is the optimization?

time to read 2 min | 295 words

Let us look at the following pieces of code:

public void Consume(MyBooksRequest message)
    var user = session.Get<User>(message.UserId);
    bus.Reply(new MyBooksResponse
        UserId = message.UserId,
        Timestamp = DateTime.Now,
        Books = user.CurrentlyReading.ToBookDtoArray()

public void Consume(MyQueueRequest message)
    var user = session.Get<User>(message.UserId);

    bus.Reply(new MyQueueResponse
        UserId = message.UserId,
        Timestamp = DateTime.Now,
        Queue = user.Queue.ToBookDtoArray()

public void Consume(MyRecommendationsRequest message)
    var user = session.Get<User>(message.UserId);

    bus.Reply(new MyRecommendationsResponse
        UserId = message.UserId,
        Timestamp = DateTime.Now,
        Recommendations = user.Recommendations.ToBookDtoArray()

Looking at this, I see that I have a requirement to getting my books, my queues and my recommendations. Looking at the code, can you guess how many queries are being generated to get those?

And can you suggest an optimization?


Benny Thomas

From my novise point it looks like you have 1 query for the user, and 3 lazyloading query's for the CurrentlyReading, Queue and Recommandations.

You don't need the user info, you should have a specialized query for only the things you need in each Cosume method.


An optimization would be to use a session.Load <user instead of a Get, so you would avoid that extra select as you are only using the ID.

Jason Meckley

I think Load would still query for the user,. You need to traverse the user to get to books.

Some approaches for optimization:

  1. Query the books directly rather than lazy loading from User.

  2. Eager load the books with the user

  3. Use Futures to retrieve the user/queue/recommendations at once and cache the results for a short period of time.

option 3 assumes the messages would be used in close succession/proximity to one-another. if they are not this doesn't provide much value. Although, if they were used that closely together, why not load all this information in a single consumer?


I see... I thought Load only triggered the query when navigating to a property that was not an association. Googled a little and found that it triggers the query when accessing to ANY property besides de id.

I agree with those other optimization approaches then.

Hudson Akridge

As Benny Thomas mentions, the lazy loads are going to hurt. Also, I'd imagine that you might encounter additional Select N+1 issues as you attempt to serialize to book dto's unless all of the information required for the serialization is on the object in the collection (which is not a given so I don't want to assume). Should probably join fetch any additional associations you have for those objects either in the mappings (not fantastic) or in the query you'd replace the Get() with.

As to how many queries to get those? Depends on how the ToDto() extension method is implemented. if there's additional associations that are lazy loaded, then it's 3(n), otherwise it should be 6 queries (one each to load the user, one more to load the collection on each).

Alexander Savvas

actually i find it a bit odd that you have a 'UserId" property on the MyXXXRequest classes. You could properly map the user on those, and then eagerly fetch the collections on the user (and eagerly fetching that User on the MyXXXRequest classes). That would lead to no additional queries (but that does not include the passed MyXXXRequest object)

Steve Py

I'd think these are 3 distinct requests so there's no point considering merging the fetches. Lazy-loading is the pain point in this example, you can fetch the associated collection eagerly, but I'd definitely avoid configuring them for eager-fetching, since a call to one method would pull back a lot of extra detail.

IMO though, retrieving the User is not required at all, just retrieve the relevant lists by UserID. (via HQL or Linq2NH) The user can be lazy-loaded should it be needed.

It would also depend on what the To Book DTO functionality was doing to ensure it wasn't attempting to dive the composition.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Making Lucene reliable - 2 hours from now
  2. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - about one day from now
  3. The design of RavenDB 4.0: Physically segregating collections - 2 days from now
  4. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  5. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now

And 13 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats