April 8, 2014 at 7:54 am
Hi all,
I'm currently working on a project at work to test the effects of database compression, trying to obtain measurable data on the impact of the compression on other server resources, and therefore whether the reduction in space used is worth the extra overhead. This has involved taking a trace of a production customer's workload for a period of time and replaying it against a backup using Distributed replay in synchronised mode. I'm then taking a trace of that replay, as well as using perfmon to record useful data about the server, before and after compression is enabled. Finally, I'm loading the traces into a tool called Qure to analyse the impact of the compression on reads, writes, CPU, overall duration etc.
What I'm finding is that even across 2 different 'baseline' runs, which are replaying the exact same workload against the exact same database, performance etc differs to a significant enough degree that it calls into question the validity of the test. I can only put this down to the fact this server is on a VM, which is affecting available resources, which in turn affects execution plans the workload is generating and causes different replays of the same workload. I'm therefore looking at doing this on a standalone server, but I still can't be sure the differences will go away.
So this leads me onto the ultimate question; does anyone have any suggestions on how to make tests such as this as similar as possible on multiple runs, when elements outside of SQL Server are in effect out of my control? I need to have confidence that the differences I'm seeing (if any) are only related to the changes I've made, so it's important to make as many aspects of the test as possible the same.
Thanks in advance
Viewing 0 posts
You must be logged in to reply to this topic. Login to reply