The new year kicked off with some big news on January 3rd, 2018 with the news of the Meltdown and Spectre chipset vulnerabilities. There are a lot of resources available to understand the details and potential impact. This one from cnet.com is pretty good.
As the patches from the operating system vendors are being rolled out, a question often comes up - "How will this impact me?" Specifically, it's the performance impact on processor utilization of applying the patches.
Patching isn't new (or at least it shouldn't be!). It's another change that you make to your computing environment that should generally have a positive impact. Whether that's a performance improvement or security fix to mitigate risk, they're generally a good thing. Any change involves uncertainty though, and it helps if we have some guidance on process.
1- Run a workload and measure where we are today (baseline).
2- Make a change - ideally with change management processes to follow.
3- Run and measure the same workload (from step 1) after the change.
4- Measure the differences to get the performance delta.
Benchmark Factory has a number of industry standard tests that are pre-packaged and ready to run, or you can collect and run your own SQL workload. This makes it easy to contain the workload and replicate it as many times as you need to. That allows an apples to apples comparison for step 4 - comparing the workloads from before and after the patching. In the example for this blog, a TPC-C test was used with a scale factor of 4, and user loads of 1-4 incremented by 1. All of these parameters are easy to set in the product.
Once the load test parameters are configured, the job is run and a real-time status panel is shown.
The change tracking feature in Foglight can be used to note when the tests started and stopped, and when the patching process began.
After the patch is applied, the Benchmark Factory load test can be re-run. This will give the "after" view of the workload performance.
In Foglight, we can drill into the workload, isolate the database that was used for the load test ("bmf_tpcc") and view the resulting impact on our SQL Server instance.
Finally, we can compare the workload impact on SQL Server between our 2 test runs using the Compare feature. We simply start with the latest available performance data (test 2) and compare it to the time period of test 1. This will let us quantify the impact between the changes. Performance comparisons can also show the differences between specific Programs, SQL Statements, etc. so that you can pinpoint exactly what was impacted.
Please visit www.quest.com for trial downloads of these products so you can measure the impact of changes within your environment!