Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Raccoon Blog Performance

DZone's Guide to

Raccoon Blog Performance

Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

Update: See below for details about the server load.

I just run into this tweet:

image

That isn’t the first time that we heard this, and it is actually surprising, not only was there no attention to performance given throughout the lifecycle of the project so far, we actually discovered some issues that theoretically should hurt performance.

The secret is that RavenDB is really good in optimizing itself based on usage patterns. That came out of the realization that we had to drop people into the Pit of Success as much as possible. Raccoon Blog shows that we were able to do just that.

Please note that I am testing this with a RavenDB server over the internet, to emphasis the actual costs involved.

For example, let us look at the current state of this blog, using RavenDB MVC Profiler:

image

Just to be clear, in order to actually show the problem, I am running this locally, while the RavenDB server is actually the production RavenDB server for this blog, in other words, the vast majority of the time is actually network traffic, making queries to RavenDB over the Internet.

Remember that I said that we didn’t pay attention to performance? Notice how many remote queries we are making. We have 5 sessions and 7 queries. Why is that?

The reason for that is that we are using the Session per Action approach for scoping the session, and we make heavy use of Child Actions, each of which is going to get its own session. Give me a moment to fix that…

Well, that took three minutes, mostly because I wanted to do it right. There are advantages for Infrastructure Ignorance, and one of them is the ease in which we can make such changes.

image

The change isn’t drastic, we went from having 5 sessions and 7 requests to 1 session and 6 requests, in the post details view, however, it saved us two requests.

The actual cost of opening a session is essentially zero, so it is more the requests that we are making than anything else. We can improve performance even further by applying additional tactics, such as aggressive caching or batched calls, but we will save those for another post.

Update: I was asked about the load, and I hopped off to Google Analytics and got a few numbers:

image

That isn’t super high, but it is respectable.

3 Steps to Monitoring in a Connected Enterprise. Check out xMatters.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}