RavenDB MVC Profiler Support
I am not sure if you have noticed, but for the last few weeks, we have had a small tag on the top left side of the blog. Clicking on this would reveal the following information:
As you can see, generating the main page took 6 sessions and 8 calls to the RavenDB server. This reflect the fact that when building RaccoonBlog, we were far more focused on the architecture and paid very little attention to the actual performance of the system and mostly focus on being correct and architecturally sound.
I’ll point out that with no attention to performance, the new blog out performs the old blog quite handily.
We can dig a bit deeper into what is going on here:
As you can see, we have a list of requests made to the server, including all of the queries made. This make it quite easy to figure out what is actually going on. For bonus points, we can even dig deeper and look at an individual request:
From debugging stand point, it is incredibly helpful. From a performance optimization perspective, it is invaluable. This feature alone has been responsible for three different bug fixes (all of them very hard to figure out without it) and has guided us into several performance improvements for the blog.
We took the idea from the Mini MVC Profiler, I really liked the idea of that, but didn’t really like the code, so we set out to build Raven.Client.MvcIntegration.dll.
In your MVC application, you need to reference that assembly and:
- In the Application_Start method, call Raven.Client.MvcIntegration.RavenProfiler.InitializeFor(documentStore).
- In your main layout, include the following line: @Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()
That would setup the RavenDB Profiler for MVC applications, giving you direct access to whatever is going on in that request. We even handle Ajax requests as well
And a minor point as well, this feature is probably not something that you would use in production, but since I wanted to show it off for you, I made sure that it can be run in production. In order to facilitate this, there is a way to redact the information sent to the client, scrubbing it from any personal information. That has been done on this blog, but it is a fairly simple system, compromised mostly of the ability to black list specific fields by name. I would be careful when exposing this to the world, but especially if you are using this to see what is going on against a remote RavenDB instance, it can be invaluable tool.
One of the requests is to
/databases/blog.ayende.com/indexes/Posts/ByMonthPublished/Count, but has two sort parameters. Does this affect performance in any way in raven?
Possibly on large datasets, but as that index is going to return at most 120 (12 * 10, for ~10 years of blog entires), I don't think it's a big problem. Lucene is pretty fast at searching and sorting.
I like the Response Headers...
What about non-MVC application? How can they be profiled? Even for MVC application I would really like to have a standalone version too, because someone (like me) might want to start the profiler on a running production server and monitor database-usage "live"...
With NHProfiler I do this quite often for production servers and would like to do that with Raven too.
"When building RavenDB"
You mean "When building Racoonblog" surely? One would rather hope that performance was cared about when building RavenDB ;-)
Configurator, It doesn't really matter, really. Sorting has some additional cost, of course, but that is about it.
Daniel, For non MVC apps, we have a debugger visualizer, and we probably will have something more in the future.
Rob, Um, yes. :-) I actually get them confused on a regular basis, thanks, I fixed that.
Ayende, Please let us know, when "RVProfiler" is ready, but I have no doubt you won't... Beside that, there seem to be some issues with your blog: the comments dates are completely wrong (in the future) and your nick also links to ayende.com/blog/blog.
How do you scale RavenDb horizontally? Can you? If you need to add node to a cluster, are the clients aware of the change?
Is this available on Nuget?
Jeff, RavenDB supports sharding OOTB. You need to using ShardingDocumentStore instead of DocumentStore, but except for that, it is the same for all client code.
Anonymious, Not yet, will be in the next stable build
@Ayende - thanks, I have some more questions, but I'll take them offline and send you an email if that's ok.
Daniel, Thanks, this is now fixed
Great little tool.
I had a page with three html tables on, all using the same query result (displaying 'published', 'draft' and 'trashed' posts) and only the one query in my controller. I thought I had it running as efficiently as possible, but having setup the profiler I noticed it was actually making three GET requests to raven. After a little investigation I discovered calling ToList() on my query results reduced those requests down to the one I was expecting.
I would've never noticed those three requests if it weren't for the profiler. Thanks for the great work.
Matt, Yep, that is exactly the idea. To make sure that you are aware about what is going on in your application, and make it EASY