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 ravendb, 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.