After seeing an interesting blog post on AnandTech IT last week that showed slower query response time in x64 SQL Server 2008 running on x64 Windows Server 2008 when using the default “Balanced” power plan compared to the “High performance” power plan (in Windows), I decided to do some investigation of my own.

I found this KB article from Microsoft: SQL Server timing values may be incorrect when you use utilities or technologies that change CPU frequencies, which seemed somewhat relevant even though it refers to SQL Server 2005 SP2.

Then I decided to run the GeekBench 2.1.4 benchmark on an ASUS P7P55D motherboard, with a 2.8GHz Intel Core i7 860 CPU and 8GB of DDR3 RAM to see if I would see any performance difference on this processor and memory intensive benchmark. It turns out that I saw a very significant difference with different BIOS settings and Windows Power Plans.

With Intel Enhanced Speed Step and Intel TurboBoost enabled in the BIOS, I got the following GeekBench scores:

“Balanced” Power Plan                   6450

“High performance” Power Plan     7860

The High performance power plan showed a 22% increase over the default Balanced power plan (in an average of five runs).

Next, I rebooted the machine and went into the BIOS setup, and disabled Intel Enhanced Speed Step (which also disables Intel TurboBoost on this motherboard. Running GeekBench five times gave me these average scores:

“Balanced” Power Plan                   7323

“High performance” Power Plan     7330

This shows the effect of TurboBoost also being disabled (which happens on this motherboard when you disable Enhanced Speed Step) on the Intel Core i7 860 CPU (which is the equivalent of the Xeon X3460). The  benchmark scores for the two Windows power plans were the same (within the margin of error) because Enhanced Speed Step was disabled in the BIOS, so Windows 2008 R2 was not able to throttle back the CPU frequency when the processor was lightly loaded.

You can get to the Power Options screen by typing powercfg.cpl in a Run prompt.

Of course, this is just a synthetic benchmark, run on one machine so far, but it does give me some food for thought (and further testing with additional machines and with SQL Server specific benchmarks).  As always, YMMV, and you should do your own testing with your workload in your own environment before you change this setting.