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.
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.
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:
- TechNet Blog: Have a look at Windows Server 2008 R2 default Power plan
- Scott Hanselman’s blog: The New Turbo Button – Balancing Power Management and Performance on Windows Servers
- Server Fault: Does CPU power management affect server performance?
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.