Reading up on Windows Server 2008 R2

For reasons I would rather not into detail about, I had to help with setting up a Windows Server 2008 R2 machine. Researching this, I found this great video on Channel 9 from PDC 2009 by Mark Russinovich: Windows 7 and Windows Server 2008 R2 Kernel Changes Part 1 and Part 2.

Here are a couple of the key takeaways from that talk from a performance point-of-view.


It’s been said before and even made it into a Forbes article, but it’s worth repeating, because many applications (even major ones) get it wrong anyway:

Don’t mess with the system timer resolution (via timeBeginPeriod) because it will increase overhead and thus reduce performance.

I remember having a system where Sysinternals ClockRes showed the timer resolution being way higher (i.e. lower tick interval) than it should have been. Unfortunately, I had no idea what application was responsible for this. In Server 2008 R2, however, one has a way of finding out:

powercfg.exe -energy duration 5

This will produce an HTML report showing you a couple of things that can have an impact on your system’s power consumption (and performance), including the processes that changed the timer resolution.

Power Plan

Also in this report is your system’s power plan. The default is Balanced, which may not be the best choice under certain circumstances. I found a couple of good articles on the topic:

Scott Hanselman’s blog post in particular left me convinced that High Performance was the way to go, given my intended use for this server is pretty close to what he described.

Dispatcher Lock Gone

In my own testing I noticed that the same application on Windows Server 2008 R2 was scaling much better with more threads than it did on Windows Server 2003 (R2). I’m not sure I have (the absence of) the dispatcher lock (see also this video on Channel 9) to thank for that, but I here’s what I noticed:

  • On Server 2003, multiple threads would not use all of the available CPU, and queues of outgoing messages would built up. Distributing the work over more threads did not improve overall throughput.
  • On Server 2008 R2 with the same number of threads, there were no queues in data processing and we reached a limit only when the NIC exceeded 90% utilization.

This was far better than I had expected. To be fair, I have not tested to what degree the increase in performance can be attributed to newer hardware versus the newer operating system. But since I can’t have one without the other, I don’t think it matters.

A Cautionary Tale

I am not entirely sure whether this is related to the absence of the dispatcher lock, but migrating to Server 2008 R2 also revealed a very nasty concurrency problem in one application. The code had been running fine for many years on Server 2003, but failed rather quickly on Server 2008 R2. My guess is that the increased degree of parallelism in 2008 R2 just made it more likely for the race condition to reveal itself.

It also shows that upgrading from 2003 to 2008 R2 (or newer) does require some testing. Even though I have not run into any APIs that were changed, there appear to be subtle timing changes such as this one that could make an application stumble.


I was pretty amazed how much better our Server 2008 R2 machines performed compared to the old 2003 machines after checking the settings mentioned above. If there are other’s I have missed, please leave a comment.

I still have to research the changes coming in Server 2012 (R2), maybe Windows Server got even better in that version.


Experimenting Some More

Normally, on a Sunday like this I would go running in one of the nearby parks. However, a month ago Düsseldorf was struck by one of the worst storms in recent history and about 17 000 trees in this city alone were destroyed or damaged.

The fire department (helped by other emergency services and even combat engineers from the army) did a tremendous job clearing the streets and allowing public transportation to resume within a few days. Despite the severity of the storm, the impact on public life was rather low.

The city’s many other patches of green including the parks I use to go for a run, though, are still not entirely safe again. So many of them have been closed off to the public out of fear that some loose branches might fall down (although I haven’t heard of anybody getting injured after the initial storm).

So instead of running, I took out my camera and shot what the areas I would usually run at looked like. Not a pretty picture.

Panorama Black & White

Detail Black & White

On a more positive note, here’s a shot I did experimenting with my new 18-250mm lens last week. After borrowing my father’s lens a while ago, I was so taken with its possibilities, I just had to get my own.

By the way, the bottom picture in that post was taken in the same park (though not the same spot) as the ones above. Once the park is accessible again, I’ll try to recreate the shot. I’m afraid there is going to be considerably less green there.