Home/ Questions/Q 7855261
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T20:19:56+00:00

I started porting a simple ASP.NET MVC web app from SQL to RavenDB. I

  • 0

I started porting a simple ASP.NET MVC web app from SQL to RavenDB. I noticed that the pages were faster on SQL than on RavenDB.

Drilling down with Miniprofiler it seems the culprit is the time it takes to do: session.SaveChanges (150-220ms). The code for saving in RavenDB looks like:

var btime = new TimeData() { Time1 = DateTime.Now, TheDay = new DateTime(2012, 4, 3), UserId = 76 };
session.Store(btime);
session.SaveChanges();

Authentication Mode: When RavenDB is running as a service, I assume it using “Windows Authentication”. When deployed as an IIS application I just used the defaults – which was “Windows Authentication”.

Background: The database machine is separate from my development machine which acts as the web server. The databases are running on the same database machine. The test data is quite small – say 100 rows. The queries are simple returning an object with 12 properties 48 bytes in size. Using fiddler to run a WCAT test against RavenDB generated higher utilization on the database machine (vs SQL) and far fewer pages. I tried running Raven as a service and as an IIS application, but didn’t see a noticible difference.

Edit

I wanted to ensure it wasn’t a problem with a) one of my machines or b) the solution I created. So, decided to try testing it on Appharbor using another solution created by Michael Friis: RavenDN sample app and simply add Miniprofiler to that solution. Michael is one of the awesome guys at Apharbor and you can download the code here if you want to look at it.

Results from Appharbor

You can try it here (for now):

  1. Read: (7-12ms with a few outliers at 100+ms).

  2. Write/Save: (197-312ms) * WOW that’s a long time to save *. To test the save, just create a new “thingy” and save it. You might want to do it at least twice since the first one usually takes longer as the application warms up.

Unless we’re both doing something wrong, RavenDB is very slow to save – around 10-20x slower to save than read. Given that it re-indexes asynchronously, this seems very slow.

Are there ways to speed it up or is this to be expected?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First – Ayende is “the man” behind RavenDB (he wrote it). I have no idea why he’s not addressing the question, although even in the Google groups, he seems to chime in once to ask some pointed questions, but rarely comes back to provide a complete answer. Maybe he’s working hard to to get RavenHQ off the ground?!?

    Second – We experienced a similar problem. Below’s a link to a discussion on Google Groups that may be the cause:

    RavenDB Authentication and 401 Response.

    A reasonable question might be: “If these recommendations fix the problem, why doesn’t RavenDB work that way out of the box?” or at least provide documentation about how to get decent write performance.

    We played for a while with the suggestions that were made in the thread above and the response-time did improve. In the end though, we switched back to MySQL because it’s well-tested, we ran into this problem early (luckily) which caused concern that we might hit more problems and, finally, because we did not have the time to:

    1. fully test whether it fixed the performance problems we saw on the RavenDB Server
    2. investigate and test the implications of using UnsafeAuthenticatedConnectionSharing & pre-authentication.
    • 0