Export (0) Print
Expand All

Test Scenario 2: Multiple VMs Using a Physical SQL Server

The purpose of test scenario two was to determine the performance that could be attained from hosting multiple Hyper-V virtual machines on the same physical server. This was then compared to a physical BizTalk Server, which had the same number of logical processors as the combined total of the virtual processors allocated to the virtual machines.

For test scenario two, the same infrastructure was used as test scenario one. Multiple virtual machines were instantiated on the Hyper-V server Hyper-V_01. This is illustrated in the diagram below.

Physical BizTalk Server Scenario

Cc768522.64e7f7d1-77d3-4ff5-aa01-447f1eb19ea4(en-US,BTS.10).gif

Virtual BizTalk Server Scenario

Cc768522.75ef5f7f-c06e-4b7c-a263-d8901501bdd8(en-US,BTS.10).gif

Test Configuration

The number of messages and number of test clients was altered according to the number of virtual BizTalk Servers running. The test conditions are detailed under each comparison below.

Optimizations Applied

In order to tune the system to attain these results, in addition to the standard platform optimizations such as database file separation, the following optimizations were performed:

  • The MaxReceiveInterval for all service classes was set to 100 ms.

  • To ensure outbound HTTP connections were not a bottleneck, the max connections for endpoints were set to 300 for all machines. For more information, see the “Setting SOAP and HTTP Adapter Concurrent Connections” topic in the BizTalk Server Operations Guide http://go.microsoft.com/fwlink/?LinkId=122179.

For more information about tuning BizTalk Server, see the “Optimizing BizTalk Server Performance” section of the Microsoft BizTalk Server Performance Optimizations Guide at http://go.microsoft.com/fwlink/?LinkId=122180.

The table below summarizes how BizTalk Server performance compares on multiple virtual machines compared to a physical server with the same amount of processors. With a one and two virtual processors allocated to a single BizTalk Server virtual machine, throughput was 73% and 75%, respectively, compared to a physical machine.

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

1-Processor (Core) Physical BizTalk Server

36.6

619

1-Processor (Core) Virtual BizTalk Server

26.8

438

2-Processor (Core) Physical BizTalk Server

47.4

540

2-Processor (Core) Virtual BizTalk Server

36

450

4-Processor (Core) Physical BizTalk Server

80.3

597

Four Virtual BizTalk Servers at 1-processor (core) each*

70

695.75

8-Processor (Core) Physical BizTalk Server

116.4

852

Four Virtual BizTalk Servers at 2-processors (cores) each

84.8

686

* Four virtual machines, each with one virtual processor, were able to process 87% of the load of a single physical machine with four logical processors available. In the Overload Scenario – Allocating Virtual Processors results section, this test was repeated with the physical server used for Hyper-V reduced to 4 logical processors. When four virtual machines were run on this configuration with an identical test configuration, the performance dropped from 87% to 71% relative to the documents per second processed on the physical hardware. When two virtual processors were assigned to the four virtual machines they were able to process 73% of the load of a comparable physical server, which had eight logical processors assigned to it, which remains consistent with the other numbers (in the 71-75% range).

These results indicate that as multiple BizTalk Server virtual machines are hosted on a Hyper-V Server, the performance that can be expected is between 71-75% of a physical BizTalk Server with the equivalent number of logical processors available. The relative performance degradation that occurred when the four virtual machines with one virtual processor were performed on an eight logical processor and four logical processer server suggests that if the total number of virtual processors running is less than the number of logical processors available in the physical Hyper-V server, an improved level of performance may be observed. This is because Hyper-V shares logical processor resources amongst virtual processors in a round-robin fashion. This is covered in more detail in the Measuring Performance on Hyper-V topic of this guide.

Cc768522.note(en-US,BTS.10).gifNote
* See the Overload Scenario – Allocating Virtual Processors topic to see how performance was affected by reducing the number of logical processors available to the root machine.

Cc768522.9e06f04c-6bfa-49bd-8a41-7f990f9a99ad(en-US,BTS.10).gif

Cc768522.b3383643-bbb5-4d54-9dfb-3f8d6aace20d(en-US,BTS.10).gif

This test was performed to determine the performance characteristics of a physical BizTalk Server running with two logical processors available compared to two virtual BizTalk Servers running with one virtual processor available to each virtual machine.

Machine Configuration

Physical machine configuration:

  • Two logical processors available to the operating system

  • 1.5 GB of memory allocated to both machines

    Cc768522.note(en-US,BTS.10).gifNote
    Additional memory was not allocated to the physical machine. The Available Mbytes counter was monitored throughout the tests duration to ensure the system was not under memory pressure, and, therefore, that this was not accounting for any variation in results.

Virtual machines configuration:

  • One virtual processor available to the operating system

  • 1.5 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • 20,000 messages sent in total by two load generator

  • Loadgen configuration

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

For the physical server, both load generators were configured to use the single Web service exposed by BizTalk Server. On the virtual machines, one load generator was configured to use each server.

Results Analysis

With this configuration, the documents processed per second was almost identical for the physical server (47.4) compared to the combined rate of the two virtual machines (46.6). The average latency recorded for two virtual machines (621 ms) was 20% higher than the physical BizTalk Server (540 ms).

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

2-Processor (Core) Physical BizTalk Server

64

540

47.4

93.5

N\A

28.2

Two Virtual BizTalk Servers at 1-processor (core) each

62

621

46.6

82.3 (average across both virtual machines)

75

28.1

Cc768522.672d8b3d-060b-4ea5-bdb2-b7c11118eccc(en-US,BTS.10).gif

Cc768522.940dc533-fa8c-4dda-9aac-20e2702ff741(en-US,BTS.10).gif

This test was performed to determine the performance characteristics of a physical BizTalk Server running with four logical processors available compared to four virtual BizTalk Servers running with one virtual processor available to each virtual machine.

Machine Configuration

Physical machine configuration:

  • Four logical processors available to the operating system

  • 1.5 GB of memory allocated to both machines

    Cc768522.note(en-US,BTS.10).gifNote
    Additional memory was not allocated to the physical machine. The Available Mbytes counter was monitored throughout the tests duration to ensure the system was not under memory pressure, and, therefore, this was not accounting for any variation in results.

Virtual machines configuration:

  • One virtual processor available to the operating system

  • 1.5 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • 20,000 messages sent in total by two load generator

  • Loadgen configuration

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

For the physical server, both load generators were configured to use the single Web service exposed by BizTalk Server. On the virtual machines, one load generator was configured to use each server.

Results Analysis

The results show that in this scenario, the physical BizTalk Server was able to process approximately 14% more documents per second than the combined total of the four virtual BizTalk Servers. Latency was 16% higher on the virtual servers compared to the physical one. The average processor utilization throughout the whole test run was lower on the virtual machines (71% compared to 93.2 on the physical server), however, this was skewed somewhat because not all of the machines completed at the same time.

Cc768522.note(en-US,BTS.10).gif
It is important to note that there is generally a trade-off in BizTalk systems between throughput and latency. Higher throughput typically equates to increased latency. With all other things being equal, a BizTalk Server solution running on physical hardware will provide higher throughput than a BizTalk Server solution running on virtual machines. This is due to the overhead that the virtual processor has when executing hypervisor code. In this scenario, it is possible that the BizTalk Server solution running on virtual machines will actually provide improved latency as compared to the BizTalk Server solution running on physical hardware.

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

4-Processor (Core) Physical BizTalk Server

65

597

80.3

93.2

N\A

53.3

Four Virtual BizTalk Servers at 1-processor (core) each

67

697.75

70

71

66.5

50

This test was performed to determine the performance characteristics of a physical BizTalk Server running with eight logical processors available to it compared to four virtual BizTalk Servers running with two virtual processors available to each virtual machine.

Machine Configuration

Physical machine configuration:

  • Four logical processors available to the operating system

  • 4 GB of memory allocated to the machine

Virtual machines configuration:

  • Two virtual processors available to the operating system

  • 1.5 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • 40,000 messages sent in total by four load generator to the virtual machines

    Cc768522.note(en-US,BTS.10).gifNote
    For an ideal comparison, an identical number of messages would have been sent through both the physical and virtual environments.

  • 100,000 messages sent in total by four load generators to the physical machine

  • Loadgen configuration

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

For the physical server, both load generators were configured to use the single Web service exposed by BizTalk Server. On the virtual machines, one load generator was configured to use each server.

Results Analysis

The physical BizTalk Server was able to process 37% more documents per second; however, the latency was 25% higher. In tests, latency of a BizTalk Server solution often increases with SQL Server CPU utilization on the MessageBox server. The physical server placed more load on SQL Server (82.3% vs. 62.6% with the virtual configuration), therefore this is the most likely cause of the increased latency 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

8-Processor (Core) Physical BizTalk Server

68

852

116.4

78.8

N\A

82.3

Four Virtual BizTalk Servers at 2-processors (cores) each

80

686

84.8

71.25

61.5

62.6

Cc768522.457d9cda-5b8d-431f-8a85-3f4647b38cff(en-US,BTS.10).gif

Cc768522.15bf5cf8-a6cb-417b-883f-7179c9664cf1(en-US,BTS.10).gif

On a system with eight logical processors (i.e. a dual processor, quad-core system such as the one used in this lab), it is possible to allocate more virtual processors than there are logical processors available in the server. The first diagram below illustrates two scenarios: the first where a Hyper-V machine with four logical processors is running four virtual BizTalk Server machines each with one virtual processor assigned to them. In the second scenario, there is the same number of Hyper-V virtual machines, but they have now been configured to run with two virtual processors each.

Cc768522.0c72e4d4-5bff-4e31-bf15-9983de5313c8(en-US,BTS.10).gif

In order to test the impact of assigning more virtual processors than logical processors, two tests were performed on a four-processor physical box with four virtual BizTalk Servers running. In the first case, a one-to-one virtual processor to logical processor mapping was used, in the second two virtual processors were allocated to each virtual machine. The load remained consistent. The details of the configuration are below.

Machine Configuration

Virtual machine one-to-one mapping:

  • Four virtual machines

  • One virtual processor available to the operating system

  • 1.5 GB of memory allocated to both machines*

Virtual machine overload configuration:

  • Two virtual processors available to the operating system

  • 1.5 GB of memory allocated to both machines

Test Configuration

Test client configuration:

  • 40,000 messages sent in total by four load generator to the virtual machines*

  • Loadgen configuration

    • Sleep Interval - 1

    • Threads Per Section – 35

    • LotSize – 4

Results Analysis

The results show that the processing capabilities of the machines decreased when more virtual processors were allocated to the machine than there were logical processors available. Performance decreased by 18% from 57 documents per second to 47 and latency also increased by 30% when a 1-to-1 mapping of virtual to logical processors was not used of. To view actual CPU utilization of the overall server from performance monitor, the %Total Run Time\Hyper V (Hyper-V_01) Hypervisor Logical Processors counter from the root partition was used. The total utilization of the server increased from an average of 79% to 95% when a non 1-to-1 mapping was used.

Cc768522.note(en-US,BTS.10).gif
In the overload scenario the %Guest Run Time performance monitor counter was very low at 38.25%. This is because each virtual processor attempted to consume 25% of the available system resources, or 8 * 25% = 200% of the processor resources that were actually available. The net effect of overloading virtual processors to available logical processors is that each virtual processor %Guest Run Time value will be low due to excessive context switching.

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 % Total Run Time\Hyper-V (Hyper-V_01) Hypervisor Logical Processors

1-Processor (Core) in each Virtual BizTalk Server

85

663.5

57

77.25

64.75

42

79

2-Processors (Cores) in each Virtual BizTalk Server

82

866.75

47

74.5

38.25

38

95

Cc768522.015f6054-f9ba-4682-9a45-8e9cae2db254(en-US,BTS.10).gif

Cc768522.16d6a0a5-f426-438b-9411-28c035aa953d(en-US,BTS.10).gif

The results of this test demonstrate that when provisioning new machines, over-allocating virtual processors on a Hyper-V machine can strain the system and cause performance degradation. In this case, the CPU became a bottleneck due to an excessive demand placed on the logical processors when a non 1-to-1 mapping was used. This indicates that when provisioning new virtual machines, careful consideration should be made of the overall load that will be put on the system.

The following image shows the settings tab in the Hyper-V manager for a virtual machine. From here, multiple virtual processors can be assigned to a machine, based on the number of logical processors in the system Hyper-V determines the total amount of system CPU resources that the machine can use. In this example, two virtual processors are allocated to a machine with eight logical processors; Hyper-V will therefore restrict the CPU utilization of this virtual machine to 25% system resource usage. When allocating processors to a virtual machine, care should be taken to consider the overall number of virtual processors that are allocated on the machine and the % Total Run Time\Hyper-V (Root Partition) Hypervisor Logical Processors should be monitored continuously to ensure that CPU utilization is not becoming a bottleneck. Note that the Hyper-V Hypervisor Virtual Processor performance monitor counters can be used to quickly look at the number of Virtual Processers on the system, but this will only display them for machines that are in the started state.

Cc768522.3dd52e81-51f2-40f5-b809-9a6767fba4a1(en-US,BTS.10).gif
Show:
© 2014 Microsoft