1,364 Posts served
5,674 Conversations started
As I have been looking at some comparisons between native performance and virtualized performance, I have noticed some key points. To get the virtualized environment as close to the native mode as possible, you need to match the number of virtual CPUs (vCPUs). Also, you need to have the amount of memory available to the VM as close as possible to the amount of memory used in the native case. An easy alternative is to have more memory than the benchmark needs in both the virtualized and native modes.
Benchmarks which are purely CPU intensive seem to perform at near native mode, when you have closely approximated the virtualized environment to the native environment. When you cannot match the number of vCPUs to the number of CPUs, the performance seems to scale appropriately (i.e. 1/2 when 4 vCPUs on an 8 CPU machine).
A group of benchmarks which seem to show a large difference between native and virtualized environments (30% to 50%) , are some database benchmarks. These benchmarks have a lot of small writes to disk (to log the database operations). In the virtualized environment (without VT-d) these have performance degradations because of the VMEXIT-real write-VMENTRY loop.
By Ajay Mungara (Intel) on May 20th, 2008 at 1:10 pm
Steven,
Thanks for a very information blog post. I was wondering if there are any features or design considerations (example: applications that performs very high disk I/O) when developing your application that risk performance degradation in a virtualized environment.
By Steven Thomsen (Intel) on May 20th, 2008 at 1:34 pm
Ajay,
The most obvious answer is to have the application store up it's small I/O writes and perform a large write. Also, if file reads are part of your application, try reading in larger chunks at a time (i.e. do not do byte at a time reads). You can alomost think of it has having a reallllllyyyyyyyyyy sssssssssssllllllllllllllllooooooooooowwwwwwwwwwww disk for your I/Os.