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

Raccoon Blog Performance

DZone's Guide to

Raccoon Blog Performance

· Performance Zone
Free Resource

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

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.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.

Topics:

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}