Export (0) Print
Expand All

Test Scenario 4: Multiple VMs and Virtual SQL Server on a Single Physical Server

In test scenario four, all virtual machines (VMs) required to run the Consume Web Service application were hosted on one physical server. This is referred to as a consolidated environment. The purpose of this scenario is to determine the processor costs of hosting SQL Server and BizTalk Server virtual machines in a consolidated environment.

The server selected for this test was HyperV_03. Six guest partitions were created on the server and then configured as four BizTalk Servers and two SQL Servers. Two BizTalk Server groups were created using two of the BizTalk Servers and a SQL Server in each group. The groups were configured similarly with the only major difference being the guest operating system for the partition on which SQL Server is installed.

Group 1 consisted of two BizTalk Server VMs and one SQL Server VM. In this group, SQL Server 2005 runs on a Windows 2008 64-bit Enterprise Edition partition. Windows Server 2008 is a fully enlightened operating system that supports up to four virtual processors, installing SQL Server on this platform was performed to determine the performance impact of adding additional processing power to a virtualized SQL Server.

Group 2 was identical to Group 1 except that SQL Server 2005 was running on a virtual machine using a Windows 2003 R2 64-bit Enterprise Edition partition. The performance of this system is compared with the results of test scenario three to determine the performance cost of a consolidated environment.

Consolidated Configuration

Cc768524.c95d71b8-4e47-4aaa-b22d-eece594be93e(en-US,BTS.10).gif

Consolidated Group 1 Configuration

Group 1 was configured with SQL Server running on Windows Server 2008. This enabled four virtual processors to be allocated to the virtual machine. The same SAN storage was attached to the physical Hyper-V machine as all the other test runs, however, the LUNs were shared between the two SQL Servers as pass-through disks (see tables below).

Name Description Operating System Memory Virtual Processors

Virtual_BTS05

BizTalk Server

Windows Server 2003 R2 64-bit Enterprise Edition

2 GB

1

Virtual_BTS06

BizTalk Server

Windows Server 2003 R2 64-bit Enterprise Edition

2 GB

1

Virtual_SQL_02

SQL Server

Windows Server 2008 64-bit Enterprise Edition

4 GB

4

Virtual_SQL02 – SAN Configuration

Drive Name Description LUN Size RAID Configuration

G:

Data_Sys

50

RAID 0 + 1

H:

Logs_Sys

50

RAID 0 + 1

I:

Data_TempDb

50

RAID 0 + 1

J:

Logs_TempDb

50

RAID 0 + 1

M:

MSDTC

5

RAID 0 + 1

Consolidated Group 2 Configuration

Group 2 was running SQL Server 2005 on Windows Server 2003 so that it could be used as a point of comparison against the tests done in test scenario three. Only two LUNs were allocated as pass-through disks to Virtual_SQL03. The database and log files for BizTalk Server and SQL Server databases were separated across the two LUNs.

Name Description Operating System Memory Virtual Processors

Virtual_BTS07

BizTalk Server

Windows Server 2003 R2 64-bit Enterprise Edition

2 GB

1

Virtual_BTS08

BizTalk Server

Windows Server 2003 R2 64-bit Enterprise Edition

2 GB

1

Virtual_SQL_03

SQL Server

Windows Server 2003 64-bit Enterprise Edition

2 GB

2

Virtual_SQL03 – SAN Configuration

Drive Name Description LUN Size RAID Configuration

G:

Data_Sys

300

RAID 0 + 1

H:

Logs_Sys

100

RAID 0 + 1

Hardware Specification

Machine Name

Hyper-V_03

Model

Dell PowerEdge R900

Processor

Quad processor, quad-core Intel Xeon CPU E7330 @2.40Ghz

Memory

32 GB

Networking

Four Network Adapters: Broadcom BCM5708C NetXtreme GigE

This section examines the relative performance of hosting multiple BizTalk groups on one consolidated physical server. Group 1 was running SQL Server 2005 on Windows Server 2008 to take advantage of the four virtual processor support that Hyper-V provides for the Windows 2008 guest operating system. Group 2 was running SQL Server 2005 on Windows Server 2003 R2 so that it could be used as a point of comparison with the virtual SQL Server tests in scenario 3.

Tests were performed with Group 1 and Group 2 running independently and then with both groups running simultaneously. The results were compared to the virtualized and physical SQL Server tests done in scenario 3.

The results from Group 2 (2 virtual processor SQL Server 2005 on Windows Server 2003 in table below) show an attainment of 79% of the throughput of the physical and virtualized SQL Servers from scenario 3 (which was running on separate hardware) when the group was run individually. With both groups running, this reduced to 70% of the throughput. Latency increased by 36% when comparing Group 2 running individually to the virtual SQL Server in performance test scenario 3. When both groups were run concurrently, this increased further to give a total of 71% increased latency.

Virtual processors execute two types of instructions: those from the virtual machine itself and those instructions required by hypervisor. Adding additional virtual processors to a Hyper-V server results in an increased amount of context switching between virtual and logical processors. The net impact of this is that a greater proportion of time is required to be spent by each virtual processor executing hypervisor instructions. If the processor utilization is already high in a virtual machine (typically defined as above 90%), adding another virtual machine to the server and hence adding additional virtual processors may result in a degradation of performance on that virtual machine. This can occur even when overall system CPU resource utilization is low. Consider either adding additional virtual processors to machines running at above 95% CPU or splitting the load amongst multiple virtual machines.

Group 1 was able to process 82% of the load of a physical 2 core SQL Server. When running Group 1, individual latency was approximately 9% lower in the virtualized environment with four virtual processors available to SQL Server than in a physical 2 core SQL Server environment, which was almost 40% lower than that of the 2-core virtual SQL Server environment in scenario 3. With both groups running simultaneously, the throughput of Group 1 did reduce to 72% of a physical 2 core SQL Server, but latency remained virtually unchanged. CPU utilization for the four virtual processor SQL Server virtual machine on Windows Server 2008 was just above 50% in both tests; therefore, it appears that it was able to execute the additional hypervisor instructions required when both groups were running simultaneously without degrading overall system performance. This supports the theory that the increase in latency in Group 2 was due to the CPU in SQL Server already been over utilized and, therefore, was unable to perform the additional hypervisor work required without degrading the performance of the virtual machine.

The consolidated BizTalk Server and SQL Server virtual machines were able to obtain approximately 80% of the throughput relative to when the virtual BizTalk Server and SQL Server machines were hosted on separate hardware. Both groups running concurrently on the same Hyper-V server were able to process approximately 70% of the load in each BizTalk group. This means there was only a 10% performance penalty associated with running two groups at the same time. From this it can be concluded that Hyper-V is capable of running multiple BizTalk Server groups at the same time in non-high throughput situations.

Name Documents/Sec Request-Response Duration Average (ms)

2 Virtual Processor SQL Server 2005 on Windows Server 2003 Alongside Group 1

27.15

1609

2 Virtual Processor SQL Server 2005 on Windows Server 2003 Running Without Group 1

30.71

1273.5

4 Virtual Processor SQL Server 2005 on Windows Server 2008 Running Alongside Group 2

28.18

541.5

4 Virtual Processor SQL Server 2005 on Windows Server 2008 Running Without Group 2

32.29

565

2 Virtual Processor SQL Server 2005 on Windows Server 2003 Running on Separate Hardware

38.5

936

2-Core Physical SQL Server

38.99

617.5

Cc768524.71c81e39-b538-4d65-88cf-94c2dd2dded9(en-US,BTS.10).gif

Cc768524.7640ca3d-dec1-4a8b-b223-8e5b75527e69(en-US,BTS.10).gif

The purpose of this test was to determine the performance of Group 2 running SQL Server 2005 on Windows Server 2003. This was compared to the performance of the same configuration in performance test scenario 3 where the SQL Server and BizTalk Server virtual machines were located on two separate servers.

Virtual_SQL03 was assigned two virtual processors and allocated 2GB of RAM for consistency with scenario 3. Tests were performed with two virtual BizTalk Servers generating load against it to determine how the virtual SQL Server coped under load and to compare it to the results from performance test scenario 3.

Cc768524.note(en-US,BTS.10).gifNote
Only Group 2’s virtual machines were running during these test runs; all other virtual machines were shut down to ensure that this did not cause any additional overhead on the server.

Machine Configuration

SQL Server configuration:

  • Two virtual processors (cores)

  • 2 GB of memory allocated to the machine

BizTalk virtual machine configuration:

  • One virtual processor (core) available to the operating system

  • 2 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • Number of messages

    • 10,000 were sent per BizTalk Server

    • Total of 20,000 messages when two VMs were used

  • Loadgen configuration:

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

Results Analysis

The table below shows the comparison of results between for two virtual BizTalk Servers generating load with the same test configuration against a physical SQL Server, a virtual SQL Server hosted on a separate box and finally in the consolidated environment. The results show that the consolidated environment was able to process over 78% of the throughput of the physical SQL Server. Latency was significantly higher at 1273 ms in the consolidated environment; this is compared to 617 ms in the physical and 936 ms in the virtual SQL Server environment on a separate box. The cause for the increased latency was the increased processor utilization in the consolidated virtual SQL Server environment. The %Processor Time reported on the SQL Server was 95.63% which indicates that CPU utilization was the bottleneck on the server, increased latency is a typical symptom that is observed in BizTalk systems when SQL CPU is under resource contention. In the previous virtual SQL Server tests %Processor Time was reported as 80.54% and 70.74% in the physical environment.

Name Run Number Request-Response Duration Average (ms) Documents/sec BizTalk CPU Utilization Hyper V % Guest Run Time (BizTalk VM instance) SQL\Processor(_Total)\% Processor Time SQLHyper V % Guest Run Time (BizTalk VM instance) Hyper-V_03\ Hyper-V Hypervisor Logical Processor(_Total)\%Total Run Time

Consolidated 2 virtual processor SQL Server

101

1273.5

30.71

76.43

62.04

95.63

79.69

24.94

2 virtual processor SQL Server

91

936

38.5

64.15

59.99

80.54

70.59

N\A

2-Core Physical SQL Server

87

617.5

38.99

71.79

65.3

70.74

N\A

N\A

The purpose of this test was to determine the performance of Group 1 running SQL Server 2005 on Windows Server 2008, which provides a fully enlightened operating system and also support for up to four virtual processors. This was compared to the performance of the same configuration in Group 1, with the only difference being that the SQL Server was running Windows Server 2003. Virtual_SQL02 was assigned four Virtual Processors and allocated 4GB of RAM. Tests were performed with two virtual BizTalk Servers generating load against it to determine how the virtual SQL Server coped under load and to compare it to the results generated in the previous test.

Cc768524.note(en-US,BTS.10).gifNote
Only the virtual machines in Group 1 were running during these test runs, all other virtual machines were shut down to ensure that this did not cause any additional overhead on the server.

Machine Configuration

SQL Server configuration:

  • Four virtual processors

  • 4 GB of memory allocated to the machine

BizTalk Server virtual machine configuration:

  • One virtual processor (core) available to the operating system

  • 2 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • Number of messages

    • 10,000 were sent per BizTalk Server

    • Total of 20,000 messages when two VMs were used

  • Loadgen configuration:

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

Results Analysis

The table below shows the comparison of results between the Group 1 Windows Server 2008 with SQL Server virtual machine and the Group 2 Windows Server 2003 virtual machine. The results show that the Windows Server 2008 with SQL Server virtual machine was able to process was able to process 5% more throughput. Latency was 44% lower in the Windows Server 2008 environment and the reported %processor time was 56% in the Windows Server 2008 vs. 95% in the Windows Server 2003. Overall, system resource usage as measured by Hyper-V HyperVisor Logical Processor\%Total Run Time was 4% higher when the SQL Server virtual machine ran on Windows Server 2008 compared to running on Windows Server 2003. This was due to the additional two virtual processor overhead.

These results indicate that the additional virtual processor support provided to the Windows Server 2008 guest operating system enable lower latency and provide additional CPU headroom. In the virtualized SQL Server tests performed in this lab, CPU utilization on the SQL Server was always the first resource to become a limiting performance factor. Therefore, we recommend installing SQL Server 2005 on Windows Server 2008 to gain the maximum virtual processor support in Hyper-V.

Name Run Number Request-Response Duration Average (ms) Documents/sec BizTalk CPU Utilization Hyper V % Guest Run Time (BizTalk VM instance) SQL\Processor(_Total)\% Processor Time SQLHyper V % Guest Run Time (BizTalk VM instance) Hyper-V_03\ Hyper-V Hypervisor Logical Processor(_Total)\%Total Run Time

4 Virtual Processor SQL Server 2005 on Windows Server 2008

98

565

32.29

79.31

62.44

56.77

50.76

28.76

2 Virtual Processor SQL Server 2005 on Windows Server 2003

101

1273.5

30.71

76.43

62.04

95.63

79.69

24.94

The purpose of this test was to determine the performance of running all BizTalk Server and SQL Server machines from Group 1 and Group 2 simultaneously on Hyper-V_03. Running SQL Server 2005 on Windows Server 2008 provides a fully enlightened operating system and also supports up to 4 virtual processors. This was compared to the performance of the same configuration in group 1, with the only difference being that the SQL Server was running Windows Server 2003. Virtual_SQL02 was assigned 4 virtual processors and allocated 4GB of RAM. Tests were performed with two virtual BizTalk Servers generating load against it to determine how the virtual SQL Server coped under load and to compare it to the results generated in the previous test.

Machine Configuration

Group 1 SQL Server configuration:

  • Four virtual processors

  • 4 GB of memory allocated to the machine

Group 2 SQL Server configuration:

  • Two virtual processors

  • 2 GB of memory allocated to the machine

Group 1 and Group 2 BizTalk Server virtual machine configuration:

  • One virtual processor (core) available to the operating system

  • 2 GB of memory allocated to both machines

Test Configuration

Two virtual BizTalk Servers were used for each BizTalk group. Four load generators were used to generate load against the total of four BizTalk Servers. The test client configuration for this test was:

  • Number of messages 10,000 were sent per BizTalk Server

    • Total of 40,000 messages as 4 VMs were used across the two BizTalk groups.

  • Loadgen configuration:

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

Results Analysis

The tables below show the performance of Group 1 and Group 2 when run simultaneously on Hyper-V_03. The results for each group running simultaneously were compared to the relative performance when they ran individually to determine the performance impact of running multiple BizTalk groups on one consolidated Hyper-V server.

Group 1 - When running alongside Group 2, the throughput of Group 1 was 87% of that obtained when it had exclusive access to the resources in Hyper-V_03. Latency was actually 4% lower when both groups were running. The values of %Guest Run time were approximately 25% lower for the BizTalk Server and SQL Server virtual processors when both groups were running. Virtual processors execute two types of instructions: those from the guest machine and those related to hypervisor code. The HyperVisor Virtual Processor\%Guest Run Time counter measures the amount of time that the virtual processor spent executing instructions from the virtual machine itself, the %Run Time represents the time the virtual processor was executing hypervisor code. Across all virtual processors the time spent in hypervisor run time increased when both groups were running. This is expected behavior and is due to the overhead associated with having additional virtual processors on the server. System CPU utilization as measured by the Hyper-V Hypervisor Logical Processor (_Total)\%Total Run Time counter increased from 28.7% to 39.5% when both groups were running, which represents a 37% increase in overall CPU utilization to accommodate two BizTalk groups.

Name Run Number Request-Response Duration Average (ms) Documents/sec BizTalk CPU Utilization Hyper V % Guest Run Time (BizTalk VM instance) SQL\Processor(_Total)\% Processor Time SQLHyper V % Guest Run Time (BizTalk VM instance) Hyper-V_03\ Hyper-V Hypervisor Logical Processor(_Total)\%Total Run Time

4 Virtual Processor SQL Server 2005 on Windows Server 2008 Running Alongside Group 2

102

541.5

28.18

72.72

46.69

52.162

39.02

39.53

4 Virtual Processor SQL Server 2005 on Windows Server 2008 Running Without Group 2

98

565

32.29

79.31

62.44

56.77

50.76

28.76

Group 2 - When running alongside Group 1, the throughput of Group 2 was 88% of that obtained when it had exclusive access to the resources in Hyper-V_03. This is consistent with the throughput results of Group 1, which was able to obtain 87% of the throughput when it had exclusive access. Latency increased by 26% when both groups were running. The values of %Guest Run time were between 15-20% lower for the BizTalk Server and SQL Server virtual processors when both groups were running. As with group 1 this meant that for all virtual processors the time spent in hypervisor run time increased when both groups were running. This is expected behavior and is due to the overhead associated with having additional virtual processors on the server.

The SQL Server virtual machine reported approximately 95% processor utilization in both tests. However, the latency increased substantially when both groups were running. SQL Server CPU performance is a common factor affecting latency. With both groups running, the virtual processor spent a greater proportion of its time executing hypervisor code. This meant that although the CPU utilization reported within the virtual machine stayed the same, there was actually less processing time available for the machine instructions. This is indicated by the decrease in %Guest Run Time when both groups were running. The net result of this was an increase in latency of the BizTalk solution due to less CPU time being available on the SQL Server.

System CPU utilization as measured by the Hyper-V Hypervisor Logical Processor (_Total)\%Total Run Time counter increased from 24.94% to 39.5% when both groups were running, which represents a relative increase of 58% in overall CPU utilization to accommodate Group 1.

Name Run Number Request-Response Duration Average (ms) Documents/sec BizTalk CPU Utilization Hyper V % Guest Run Time (BizTalk VM instance) SQL\Processor(_Total)\% Processor Time SQLHyper V % Guest Run Time (BizTalk VM instance) Hyper-V_03\ Hyper-V Hypervisor Logical Processor(_Total)\%Total Run Time

2 Virtual Processor SQL Server 2005 on Windows Server 2003 Alongside Group 1

102

1609

27.15

72.67

49.02

95.21

67.995

39.53

2 Virtual Processor SQL Server 2005 on Windows Server 2003 Running Without Group 1

101

1273.5

30.71

76.43

62.04

95.63

79.69

24.94

Conclusions

The results indicate that Hyper-V can host the virtual machines for multiple BizTalk groups with a 12-13% reduction in throughput. When adding virtual machines to a server, it is important to monitor the resource utilization of disk, memory, CPU and networking before and after the virtual machines are added to ensure that system resources do not become oversaturated.

An additional important performance factor to consider with Hyper-V is that adding additional virtual processors to a server results in more context switching between virtual and logical processors. This manifests itself in a reduction in %Guest Run Time, due to the increased amount of time that the virtual processor needs to spend executing hypervisor code.

A key learning from these results is that adding additional virtual processors to a machine results in more context switching and will result in less time being available to execute virtual machine processor instructions. For virtual machines that are operating at high CPU utilization levels (indicated by Processor\% Processor Time), be aware that this overhead of executing additional hypervisor instructions may result in degradation in the latency of throughput performance of your system. This behavior was observed in the virtual SQL Server for group 2, which was already running at over 95% CPU utilization (from the perfmon graphs the server was actually executing at 100% the majority of the time). When Group 1 and Group 2 were run simultaneously the latency increased by 26% in Group 2. Conversely Group 1’s virtual SQL Server was operating at just over 50% processor utilization when both groups were running individually and at the same time. %Guest Run Time for Group 1 decreased from 50% to 39% when both groups were running, but latency was 4% lower when both groups were running. This shows that because the virtual processors for Group 1 virtual SQL Server were not at maximum capacity they was able to accommodate the additional overhead required to execute hypervisor instructions without degrading the performance of the virtual machine.

Show:
© 2014 Microsoft