OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Performance

2011-05-26T12:01:18Z

Vlukovnikov: add link to microbenchmarks

== Benchmark results ==

This page is to collect a list of benchmark results available and demonstrate not only the words about containers technology being more superior from performance point of view compared to hypervisors but also to provide some data proving that.

{| class="wikitable"
|+ Benchmarks
|-
|| '''Benchmark''' || '''Description'''
|-
|| [[/Response Time/]]
|| Microbenchmark demonstrating latency issues of interactive applications in virtualized and loaded systems (netperf RR in various conditions).
|-
|| [[/Network Throughput/]]
|| 10Gbit simple network throughput comparison using netperf test.
|-
|| [[/LAMP/]]
|| Linux Apache+MySql+PHP (LAMP) stack benchmark in multiple simultaneously running virtualization instances.
|-
|| [[/vConsolidate-UP/]]
|| UP configuration of Intel vConsolidate server consolidation benchmark (Java+Apache+MySQL workloads).
|-
|| [[/vConsolidate-SMP/]]
|| SMP configuration of Intel vConsolidate server consolidation benchmark (Java+Apache+MySQL workloads).
|-
|| [[/Microbenchmarks/]]
|| Various microbenchmarks like context switch, system call, etc. Plus Unixbench resuls.
|}

== External sources ==
* [http://www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf HP Labs: Performance Evaluation of Virtualization Technologies for Server Consolidation]

File:Benchmark unixbench.png

2011-05-26T11:57:26Z

Vlukovnikov: uploaded a new version of "File:Benchmark unixbench.png": chart shadow added

Unixbench performance results

Performance/Microbenchmarks

2011-05-26T11:55:53Z

Vlukovnikov: results converted to charts

== Testbed Configuration ==
Hardware
* Server: HP Z800 workstation (2xQuad Core 2,67 GHz CPUs, 24 GB RAM)

Platform:
* Virtualization Software: Xen CentOS 5.5 x86_64, OpenVZ (RHEL5) 2.6.18-028stab090.4, OpenVZ (RHEL6) 2.6.32-042test0012.2.x86_64
* Guest OS: CentOS 5.5 x86_64, RHEL6

== Results ==

=== Context Switch ===

[[File:Benchmark context switch.png]]

[[File:Benchmark context switch 8proc.png]]

=== Process execve() ===

[[File:Benchmark execv.png]]

=== Process fork() ===

[[File:Benchmark fork.png]]

=== System Call ===

[[File:Benchmark syscall.png]]

=== UnixBench 5.1.3 ===

[[File:Benchmark unixbench.png]]

File:Benchmark unixbench.png

2011-05-26T11:53:19Z

Vlukovnikov: Unixbench performance results

Unixbench performance results

File:Benchmark syscall.png

2011-05-26T11:30:53Z

Vlukovnikov: System call microbenchmark performance results

System call microbenchmark performance results

File:Benchmark fork.png

2011-05-26T11:30:21Z

Vlukovnikov: Process fork() microbenchmark performance results

Process fork() microbenchmark performance results

File:Benchmark execv.png

2011-05-26T11:29:34Z

Vlukovnikov: Process execv() microbenchmark performance results

Process execv() microbenchmark performance results

File:Benchmark context switch 8proc.png

2011-05-26T11:27:46Z

Vlukovnikov: Context switch microbenchmark performance results - 8 processes

Context switch microbenchmark performance results - 8 processes

File:Benchmark context switch.png

2011-05-26T11:22:44Z

Vlukovnikov: Context switch microbenchmark performance results

Context switch microbenchmark performance results

Performance/Microbenchmarks

2011-05-26T11:17:30Z

Vlukovnikov: config corrected

== Benchmark description ==

=== Testbed Configuration ===
Hardware
* Server: HP Z800 workstation (2xQuad Core 2,67 GHz CPUs, 24 GB RAM)

Platform:
* Virtualization Software: Xen CentOS 5.5 x86_64, OpenVZ (RHEL5) 2.6.18-028stab090.4, OpenVZ (RHEL6) 2.6.32-042test0012.2.x86_64
* Guest OS: CentOS 5.5 x86_64, RHEL6

=== Results ===

{| class="wikitable"
|+ Benchmarks
|-
|| '''Operation'''
|| #1 Native CentOS 5.5 x64 kernel 2.6.18
|| #2 Xen CentOS 5.5 x64 kernel 2.6.18
|| #3 OpenVZ CentOS 5.5 x64 kernel 2.6.18
|| #4 Native RHEL 6.0 x64 kernel 2.6.32
|| #5 VzLin RHEL 6.0 x64 kernel 2.6.32
|-
|| Context switch using pipe || 251K || 126K || . || 194K || 166K
|-
|| Context switch using pipe (8 threads) || 6028K || 605K || 4807K || 3993K || 3686K
|-
|| Process execve() || 3162 || 1074 || 4217 || 8052 || 7288
|-
|| Process fork() || 4630 || 1958 || 5728 || 14773 || 14182
|-
|| System call || 4381K || 993K || 3583K || 4854K || 3408K
|}

File:VConsolidate-SMP.png

2011-05-17T14:29:20Z

Vlukovnikov: uploaded a new version of "File:VConsolidate-SMP.png": previous results were with misconfigured disk array - fixed

vConsolidate 4-way SMP performance results

Performance/vConsolidate-SMP

2011-05-16T10:18:42Z

Vlukovnikov: OpenVZ RH5 version - upgrade to 2.6.18-028stab090.4

=== Benchmark Description ===

The goal of Intel vConsolidate benchmark is to measure aggregated server performance in consolidation scenario: when different (and non-related unlike to LAMP benchmark) applications are running on the same box each in its own virtual environment (virtual machine or container).

vConsolidate benchmark was developed by Intel in cooperation with other vendors. It runs separate workloads with Java (SPECjbb test), Mail, Web and Database VMs running concurrently. Each set of such VMs is called CSU - Consolidation Stack Unit. Performance metric is a geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java. The same type of metric is commonly used in other benchmarks like those from SPEC.

vConsolidate benchmark is very similar to other virtualization specific benchmarks like VMMark from VMWare and SPECvirt, but the latter are more enterprise oriented and generate the load requiring a fast SAN storage and high end hardware. Since we believe containers benefits are even more prominent on commodity hardware we use vConsolidate benchmark to demonstrate that.

=== Implementation ===

Intel vConsolidate v1.1. We do not run Mail VM as Intel benchmark has Microsoft Windows version only for mail workload.

=== Testbed Configuration ===
Hardware:
* Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM
* Network: 1Gbit direct server <-> client connection

Platform:
* Virtualization Software: ESXi4.1up1, XenServer5.6fp1, OpenVZ (RH5) 2.6.18-028stab090.4, OpenVZ (RH6) 2.6.32-042test006.1.x86_64
* Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 4 vCPUs, 1 GB RAM
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard setting)
* Firewall was turned off
* All other settings were left as defaults

=== Benchmark Results ===

[[File:vConsolidate-SMP.png]]

=== Summary ===

OpenVZ demonstrates outstanding performance benefits over hypervisors in case of multi-processor environments and multi-threaded workloads:
* Almost 3x times better overall performance in case of single set of workloads (1 CSU).
* 2.1-2.2x times better overall performance on 5 and 10 CSU.

=== TODO ===
* add a link to paper where explaining why containers are great for SMP workloads and CPU overcommit.

File:VConsolidate-SMP.png

2011-05-16T10:16:49Z

Vlukovnikov: uploaded a new version of "File:VConsolidate-SMP.png": upgrade OpenVZ 2.6.18 results to 2.6.18-028stab090.4 kernel. +30% performance on 10 CSUs

vConsolidate 4-way SMP performance results

Performance/vConsolidate-SMP

2011-05-13T12:23:31Z

Vlukovnikov:

=== Benchmark Description ===

The goal of Intel vConsolidate benchmark is to measure aggregated server performance in consolidation scenario: when different (and non-related unlike to LAMP benchmark) applications are running on the same box each in its own virtual environment (virtual machine or container).

vConsolidate benchmark was developed by Intel in cooperation with other vendors. It runs separate workloads with Java (SPECjbb test), Mail, Web and Database VMs running concurrently. Each set of such VMs is called CSU - Consolidation Stack Unit. Performance metric is a geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java. The same type of metric is commonly used in other benchmarks like those from SPEC.

vConsolidate benchmark is very similar to other virtualization specific benchmarks like VMMark from VMWare and SPECvirt, but the latter are more enterprise oriented and generate the load requiring a fast SAN storage and high end hardware. Since we believe containers benefits are even more prominent on commodity hardware we use vConsolidate benchmark to demonstrate that.

=== Implementation ===

Intel vConsolidate v1.1. We do not run Mail VM as Intel benchmark has Microsoft Windows version only for mail workload.

=== Testbed Configuration ===
Hardware:
* Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM
* Network: 1Gbit direct server <-> client connection

Platform:
* Virtualization Software: ESXi4.1up1, XenServer5.6fp1, OpenVZ (RH5) 2.6.18-028stab085.3, OpenVZ (RH6) 2.6.32-042test006.1.x86_64
* Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 4 vCPUs, 1 GB RAM
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard setting)
* Firewall was turned off
* All other settings were left as defaults

=== Benchmark Results ===

[[File:vConsolidate-SMP.png]]

=== Summary ===

OpenVZ demonstrates outstanding performance benefits over hypervisors in case of multi-processor environments and multi-threaded workloads:
* Almost 3x times better overall performance in case of single set of workloads (1 CSU).
* 2.1-2.2x times better overall performance on 5 and 10 CSU.

=== TODO ===
* add a link to paper where explaining why containers are great for SMP workloads and CPU overcommit.

File:VConsolidate-SMP.png

2011-05-13T12:22:30Z

Vlukovnikov: uploaded a new version of "File:VConsolidate-SMP.png": ESXi4.1up1 results were added

vConsolidate 4-way SMP performance results

Performance/vConsolidate-UP

2011-04-18T10:36:13Z

Vlukovnikov:

=== Benchmark Description ===

This benchmark is designed to measure aggregated server performance in consolidation scenario: where different apps are running at the same time in separate virtual machines or operating system containers.

=== Implementation ===

We use standard industrial benchmark: vConsolidate. It was developed by Intel in cooperation with other vendors. vConsolidate measures performance from Java, Web and Db VMs running concurrently (we excluded Mail VM as it was MS Windows version only). Each set of such three VMs is called CSU - Consolidation Stack Unit.
Performance metric is geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: Gbit direct server<>client connection

Virtualization Software:ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH5) 2.6.18-028stab085.3

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard setting)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:vconsolidate-UP.png]]

[[File:vconsolidate-up-table.png]]
=== Summary ===

*TODO: write summary

File:Vconsolidate-up-table.png

2011-04-18T10:34:53Z

Vlukovnikov: vconsolidate up detailed performance results

vconsolidate up detailed performance results

Performance

2011-04-18T10:17:32Z

Vlukovnikov:

* [[/Response Time/]]
* [[/Network Throughput/]]
* [[/LAMP/]]
* [[/vConsolidate-UP/]]
* [[/vConsolidate-SMP/]]

Performance/vConsolidate-UP

2011-04-18T10:17:02Z

Vlukovnikov: Created page with '=== Benchmark Description === This benchmark is designed to measure aggregated server performance in consolidation scenario: where different apps are running at the same time in…'

File:Vconsolidate-UP.png

2011-04-18T10:13:25Z

Vlukovnikov: vconsolidate up performance results

vconsolidate up performance results

Performance/vConsolidate-SMP

2011-04-15T18:23:46Z

Vlukovnikov:

=== Benchmark Description ===

This benchmark is designed to measure aggregated server performance in consolidation scenario: where different apps are running at the same time in separate virtual machines or operating system containers.

=== Implementation ===

We use standard industrial benchmark: vConsolidate. It was developed by Intel in cooperation with other vendors. vConsolidate measures performance from Java, Web and Db VMs running concurrently (we excluded Mail VM as it was MS Windows version only). Each set of such three VMs is called CSU - Consolidation Stack Unit.
Performance metric is geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: Gbit direct server<>client connection

Virtualization Software: XenServer5.6fp1, OpenVZ (RH5) 2.6.18-028stab085.3, OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 4 vCPUs, 1 GB RAM
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard setting)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:vConsolidate-SMP.png]]

=== Summary ===

*TODO: write summary

Performance

2011-04-15T18:21:36Z

Vlukovnikov:

* [[/Response Time/]]
* [[/Network Throughput/]]
* [[/LAMP/]]
* [[/vConsolidate-SMP/]]

Performance/vConsolidate-SMP

2011-04-15T18:20:45Z

=== Benchmark Description ===

This benchmark is designed to measure aggregated server performance in consolidation scenario: where different apps are running at the same time in separate virtual machines or operating system containers.

=== Implementation ===

We use standard industrial benchmark: vConsolidate. It was developed by Intel in cooperation with other vendors. vConsolidate measures performance from Java, Web and Db VMs running concurrently (we excluded Mail VM as it was MS Windows version only). Each set of such three VMs is called CSU - Consolidation Stack Unit.
Performance metric is geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: Gbit direct server<>client connection

Virtualization Software: XenServer5.6fp1, OpenVZ (RH5) 2.6.18-028stab085.3, OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:vConsolidate-SMP.png]]

=== Summary ===

*TODO: write summary

File:VConsolidate-SMP.png

2011-04-15T18:11:13Z

Vlukovnikov: vConsolidate 4-way SMP performance results

vConsolidate 4-way SMP performance results

Performance/LAMP

2011-04-15T18:02:08Z

Vlukovnikov:

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance_v2.png]]

[[File:lamp_rt_v2.png]]

=== Summary ===

* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* OpenVZ shows the best response time over solutions tested: OpenVZ has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

Performance

2011-04-14T13:22:00Z

Vlukovnikov: Replaced content with '* Performance/Response_Time * Performance/Network_Throughput * Performance/LAMP'

* [[Performance/Response_Time]]
* [[Performance/Network_Throughput]]
* [[Performance/LAMP]]

Performance/LAMP

2011-04-14T13:15:43Z

Vlukovnikov: Created page with '=== Benchmark Description === LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many …'

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance_v2.png]]

[[File:lamp_rt_v2.png]]

=== Summary ===

* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* OpenVZ shows the best response time over solutions tested: OpenVZ has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

Performance/Response Time

2011-04-14T13:14:22Z

Vlukovnikov: Created page with 'Response Time === Benchmark Description === The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) re…'

Response Time

=== Benchmark Description ===
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:
* Idle system and idle VM/CT
* Busy system and idle VM/CT
* Busy system and busy VM/CT

Described benchmark case is common for many latency sensitive real life workloads. For example: high performance computing, image processing and rendering, web and database servers and so on.

=== Implementation ===
To measure response time we use well known netperf TCP_RR test. To emulate busy VM/CT we run CPU eater program (busyloop) inside of it. To emulate busy system we run several busy VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: 1Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64

Guest OS: CentOS 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM
* '''six''' VMs/CTs (to load server CPU - see testcases) configured with 4 vCPU, 1GB RAM
* netperf command
** in VM/CT: <code>netserver -p 30300</code>
** on the client: <code>netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128</code>
* Firewall was turned off
* All other tunables were left at default values.

=== Benchmark Results ===

[[File:Response_time_v2.png]]

'''In all the three cases (idle system and idle VM/CT, busy system and idle VM/CT, busy system and busy VM/CT) OpenVZ show the lowest overhead over all the tested virtualization solutions'''

Performance/Network Throughput

2011-04-14T13:11:56Z

Vlukovnikov: Created page with '=== Benchmark Description === In this benchmark we measure throughput over 10 Gbit network connection in two directions: * from VM/CT to physical client * from physical client t…'

=== Benchmark Description ===

In this benchmark we measure throughput over 10 Gbit network connection in two directions:
* from VM/CT to physical client
* from physical client to VM/CT

=== Implementation ===

To measure network throughput we use standard performance test '''netperf'''. Host with VM/CT and physical client connected are interconnected directly (without switches, etc.)

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: 10Gbit direct server<>client optical connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM
* where it was possible, we set offloading & hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features
* netperf run string:
** Server: netserver -p PORT (5 instances)
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:10gbit_throughput_v2.png]]

=== Summary ===

*OpenVZ support near native 10Gbit network throughput: 9.70Gbit in receive and 9.87Gbit in send tests
*OpenVZ shows the best network throughput over all the solutions tested
*In Receive performance test (physical client-> VM/CT) OpenVZ shows great benefits over hypervisors: x2 Times faster than ESXi4.1 and x5 Times faster than XenServer5.6

Performance

2011-03-23T14:18:27Z

Vlukovnikov:

== Response Time ==

=== Benchmark Description ===
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:
* Idle system and idle VM/CT
* Busy system and idle VM/CT
* Busy system and busy VM/CT

Described benchmark case is common for many latency sensitive real life workloads. For example: high performance computing, image processing and rendering, web and database servers and so on.

=== Implementation ===
To measure response time we use well known netperf TCP_RR test. To emulate busy VM/CT we run CPU eater program (busyloop) inside of it. To emulate busy system we run several busy VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: 1Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM
* '''six''' VMs/CTs (which needed to load server CPU - see testcases) configured with 4vCPU 1GB RAM
* netperf run string:
** in VM/CT; netserver -p 30300
** on the client: netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128
* Firewall was turned off
* All other tunings were left at default values.

=== Benchmark Results ===

[[File:Response_time_v2.png]]

'''In all the three cases (idle system and idle VM/CT, busy system and idle VM/CT, busy system and busy VM/CT) OpenVZ show the lowest overhead over all the tested virtualization solutions'''

== 10 Gbit Network Throughput ==

=== Benchmark Description ===

In this benchmark we measure throughput over 10 Gbit network connection in two directions:
* from VM/CT to physical client
* from physical client to VM/CT

=== Implementation ===

To measure network throughput we use standard performance test '''netperf'''. Host with VM/CT and physical client connected are interconnected directly (without switches, etc.)

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: 10Gbit direct server<>client optical connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM
* where it was possible, we set offloading & hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features
* netperf run string:
** Server: netserver -p PORT (5 instances)
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:10gbit_throughput_v2.png]]

=== Summary ===

*OpenVZ support near native 10Gbit network throughput: 9.70Gbit in receive and 9.87Gbit in send tests
*OpenVZ shows the best network throughput over all the solutions tested
*In Receive performance test (physical client-> VM/CT) OpenVZ shows great benefits over hypervisors: x2 Times faster than ESXi4.1 and x5 Times faster than XenServer5.6

== LAMP Stack ==

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance_v2.png]]

[[File:lamp_rt_v2.png]]

=== Summary ===

* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* OpenVZ shows the best response time over solutions tested: OpenVZ has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

File:Response time v2.png

2011-03-23T14:17:26Z

Vlukovnikov:

File:Lamp rt v2.png

2011-03-23T14:17:09Z

Vlukovnikov:

File:Lamp performance v2.png

2011-03-23T14:16:50Z

Vlukovnikov:

File:10gbit throughput v2.png

2011-03-23T14:16:30Z

Vlukovnikov:

File:Lamp rt.png

2011-03-22T11:57:19Z

Vlukovnikov: uploaded a new version of "File:Lamp rt.png"

File:Lamp performance.png

2011-03-22T11:56:18Z

Vlukovnikov: uploaded a new version of "File:Lamp performance.png"

File:10gbit throughput.png

2011-03-22T11:55:27Z

Vlukovnikov: uploaded a new version of "File:10gbit throughput.png"

File:Response time.png

2011-03-22T11:54:25Z

Vlukovnikov: uploaded a new version of "File:Response time.png"

Performance

2011-03-22T11:52:01Z

Vlukovnikov:

== Response Time ==

=== Benchmark Description ===
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:
* Idle system and idle VM/CT
* Busy system and idle VM/CT
* Busy system and busy VM/CT

Described benchmark case is common for many latency sensitive real life workloads. For example: high performance computing, image processing and rendering, web and database servers and so on.

=== Implementation ===
To measure response time we use well known netperf TCP_RR test. To emulate busy VM/CT we run CPU eater program (busyloop) inside of it. To emulate busy system we run several busy VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: 1Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM
* '''six''' VMs/CTs (which needed to load server CPU - see testcases) configured with 4vCPU 1GB RAM
* netperf run string:
** in VM/CT; netserver -p 30300
** on the client: netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128
* Firewall was turned off
* All other tunings were left at default values.

=== Benchmark Results ===

[[File:Response_time.png]]

'''In all the three cases (idle system and idle VM/CT, busy system and idle VM/CT, busy system and busy VM/CT) OpenVZ show the lowest overhead over all the tested virtualization solutions'''

== 10 Gbit Network Throughput ==

=== Benchmark Description ===

In this benchmark we measure throughput over 10 Gbit network connection in two directions:
* from VM/CT to physical client
* from physical client to VM/CT

=== Implementation ===

To measure network throughput we use standard performance test '''netperf'''. Host with VM/CT and physical client connected are interconnected directly (without switches, etc.)

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: 10Gbit direct server<>client optical connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM
* where it was possible, we set offloading & hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features
* netperf run string:
** Server: netserver -p PORT (5 instances)
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:10gbit_throughput.png]]

=== Summary ===

*OpenVZ support near native 10Gbit network throughput: 9.70Gbit in receive and 9.87Gbit in send tests
*OpenVZ shows the best network throughput over all the solutions tested
*In Receive performance test (physical client-> VM/CT) OpenVZ shows great benefits over hypervisors: x2 Times faster than ESXi4.1 and x5 Times faster than XenServer5.6

== LAMP Stack ==

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance.png]]

[[File:lamp_rt.png]]

=== Summary ===

* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* OpenVZ shows the best response time over solutions tested: OpenVZ has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

Performance

2011-03-22T11:51:19Z

Vlukovnikov:

== Response Time ==

=== Benchmark Description ===
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:
* Idle system and idle VM/CT
* Busy system and idle VM/CT
* Busy system and busy VM/CT

Described benchmark case is common for many latency sensitive real life workloads. For example: high performance computing, image processing and rendering, web and database servers and so on.

=== Implementation ===
To measure response time we use well known netperf TCP_RR test. To emulate busy VM/CT we run CPU eater program (busyloop) inside of it. To emulate busy system we run several busy VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: 1Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM
* '''six''' VMs/CTs (which needed to load server CPU - see testcases) configured with 4vCPU 1GB RAM
* netperf run string:
** in VM/CT; netserver -p 30300
** on the client: netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128
* Firewall was turned off
* All other tunings were left at default values.

=== Benchmark Results ===

[[File:Response_time.png]]

'''In all the three cases (idle system and idle VM/CT, busy system and idle VM/CT, busy system and busy VM/CT) Virtuozzo Containers show the lowest overhead over all the tested virtualization solutions'''

== 10 Gbit Network Throughput ==

=== Benchmark Description ===

In this benchmark we measure throughput over 10 Gbit network connection in two directions:
* from VM/CT to physical client
* from physical client to VM/CT

=== Implementation ===

To measure network throughput we use standard performance test '''netperf'''. Host with VM/CT and physical client connected are interconnected directly (without switches, etc.)

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: 10Gbit direct server<>client optical connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM
* where it was possible, we set offloading & hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features
* netperf run string:
** Server: netserver -p PORT (5 instances)
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:10gbit_throughput.png]]

=== Summary ===

*OpenVZ support near native 10Gbit network throughput: 9.70Gbit in receive and 9.87Gbit in send tests
*OpenVZ shows the best network throughput over all the solutions tested
*In Receive performance test (physical client-> VM/CT) OpenVZ shows great benefits over hypervisors: x2 Times faster than ESXi4.1 and x5 Times faster than XenServer5.6

== LAMP Stack ==

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance.png]]

[[File:lamp_rt.png]]

=== Summary ===

* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* OpenVZ shows the best response time over solutions tested: OpenVZ has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

File:Lamp rt.png

2011-03-22T10:59:57Z

Vlukovnikov: uploaded a new version of "File:Lamp rt.png"

File:Lamp performance.png

2011-03-22T10:59:06Z

Vlukovnikov: uploaded a new version of "File:Lamp performance.png"

File:Lamp performance.png

2011-03-22T10:57:30Z

Vlukovnikov: uploaded a new version of "File:Lamp performance.png"

File:10gbit throughput.png

2011-03-22T10:56:33Z

Vlukovnikov: uploaded a new version of "File:10gbit throughput.png"

File:Response time.png

2011-03-22T10:53:40Z

Vlukovnikov: uploaded a new version of "File:Response time.png"

Performance

2011-03-21T16:48:26Z

Vlukovnikov:

== Response Time ==

=== Benchmark Description ===
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:
* Idle system and idle VM/CT
* Busy system and idle VM/CT
* Busy system and busy VM/CT

Described benchmark case is common for many latency sensitive real life workloads. For example: high performance computing, image processing and rendering, web and database servers and so on.

=== Implementation ===
To measure response time we use well known netperf TCP_RR test. To emulate busy VM/CT we run CPU eater program (busyloop) inside of it. To emulate busy system we run several busy VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM

Network: 1Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), PVC 4.7 (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM
* '''six''' VMs/CTs (which needed to load server CPU - see testcases) configured with 4vCPU 1GB RAM
* netperf run string:
** in VM/CT; netserver -p 30300
** on the client: netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128
* Firewall was turned off
* All other tunings were left at default values.

=== Benchmark Results ===

[[File:Response_time.png]]

'''In all the three cases (idle system and idle VM/CT, busy system and idle VM/CT, busy system and busy VM/CT) Virtuozzo Containers show the lowest overhead over all the tested virtualization solutions'''

== 10 Gbit Network Throughput ==

=== Benchmark Description ===

In this benchmark we measure throughput over 10 Gbit network connection in two directions:
* from VM/CT to physical client
* from physical client to VM/CT

=== Implementation ===

To measure network throughput we use standard performance test '''netperf'''. Host with VM/CT and physical client connected are interconnected directly (without switches, etc.)

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: 10Gbit direct server<>client optical connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), PVC 4.7 (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* netperf v2.4.5
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM
* where it was possible, we set offloading & hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features
* netperf run string:
** Server: netserver -p PORT (5 instances)
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:10gbit_throughput.png]]

=== Summary ===

*Parallels Virtuozzo Containers support near native 10Gbit network throughput: 9.70Gbit in receive and 9.87Gbit in send tests
*Parallels Virtuozzo Containers shows the best network throughput over all the solutions tested
*In Receive performance test (physical client-> VM/CT) Parallels Virtuozzo Containers shows great benefits over hypervisors: x2 Times faster than ESXi4.1 and x5 Times faster than XenServer5.6

== LAMP Stack ==

=== Benchmark Description ===
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites. We measure not only performance (how many requests can deliver server), but also maximum response time - to understand QoS.

=== Implementation ===

To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell].

=== Testbed Configuration ===
Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0

Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card

Network: Gbit direct server<>client connection

Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), PVC 4.7 (RH6) 2.6.32-042test006.1.x86_64

Guest OS: Centos 5.5 x86_64

Software and Tunings:
* Each VM/CT was configured with 1 vCPU, 1 GB RAM
* Small db was deployed from DVD Store samples
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1
* Firewall was turned off
* All other tunings were left at default values

=== Benchmark Results ===

[[File:lamp_performance.png]]

[[File:lamp_rt.png]]

=== Summary ===

* Parallels Virtuozzo Containers shows the best performance over solutions tested: PVC 38% faster than XenServer and more than x2 times faster than HyperV and ESXi
* Parallels Virtuozzo Containers shows the best response time over solutions tested: PVC has 33% better response time than ESXi and x2 times better response time than XenServer and HyperV

File:Lamp rt.png

2011-03-21T16:35:39Z

Vlukovnikov:

File:Lamp performance.png

2011-03-21T16:35:20Z

Vlukovnikov:

Performance

2011-03-21T13:58:22Z

Vlukovnikov: /* Summary */

Performance

2011-03-21T13:57:50Z

Vlukovnikov: /* 10 Gbit Network Throughput */