Difference between revisions of "Performance/vConsolidate-UP"
Vlukovnikov (talk | contribs) (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…') |
Vlukovnikov (talk | contribs) |
||
| Line 30: | Line 30: | ||
[[File:vconsolidate-UP.png]] | [[File:vconsolidate-UP.png]] | ||
| + | [[File:vconsolidate-up-table.png]] | ||
=== Summary === | === Summary === | ||
*TODO: write summary | *TODO: write summary | ||
Revision as of 10:36, 18 April 2011
Contents
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
Summary
- TODO: write summary
