In a series of blogs, we showed that not only can Docker containers seamlessly run inside vSphere 6.0 VMs, but both micro-benchmarks and popular workloads in such configurations perform as well as, and in some cases better than, in native Docker configurations.
See the following blog posts for our past findings:
- Docker Containers Performance in VMware vSphere: We studied the performance of running Docker containers on vSphere by running a single instance of an application (Redis) and some micro-benchmarks.
- Scaling Out Redis Performance with Docker on vSphere 6.0: We presented the performance of a scaled-out Redis deployment and showed that running Docker containers in a vSphere VM can surprisingly provide better performance than running Docker containers out of the box in a native environment.
- Scaling Web 2.0 Applications Using Docker Containers on vSphere 6.0: We used a benchmark that simulates a java Web application (CloudStone) and show that performance using virtual machines is very close to native and, in certain cases, slightly better due to better vSphere scheduling and isolation.
In this blog, we study a transactional database workload and present the results on how Docker containers perform in a VM when we scale out the number of database instances. To do this experiment, we use DVD Store 2.1, which is an OLTP benchmark that supports and stresses many different back-end databases including Microsoft SQL Server, Oracle Database, MySQL, and PostgreSQL. This benchmark is open source and the latest version 2.1 is available here. It is a 3-tier application with a Web server, an application server, and a backend database server. The benchmark simulates a DVD store, where customers log in, browse, and order DVD products. The tool is designed to utilize a number of advanced database features including transactions, stored procedures, triggers, and referential integrity. The main transactions are (1) add new customers, (2) log in customers, (3) browse DVDs, (4) enter purchase orders, and (5) re-order stock. The client driver is written in C# and is usually run from Windows; however, the client can be run on Linux using the Mono framework. The primary performance metric of the benchmark is orders per minute (OPM).
In our experiments, we used a PostgreSQL database with an Apache Web server, and the application logic was implemented in PHP. In all tests we ran 16 instances of DVD Store, where each instance comprises all 3-tiers. We found that, due to better scheduling, running Docker in a VM in a scale-out scenario can provide better throughput than running a Docker container in a native system.
Next, we present the configurations, benchmarks, detailed setup, and the performance results.
Deployment Scenarios
We compare four different scenarios, as illustrated below:
– Native: Linux OS running directly on hardware (Ubuntu 14.04.1)
– vSphere VM: vSphere 6.0 with VMFS5, in 8 VMs, each with the same guest OS as native
– Native-Docker: Docker 1.5 running on a native OS (Ubuntu 14.04.1)
– VM-Docker: Docker 1.5 running in each of 8 VMs on a vSphere host
In each configuration, all of the power management features were disabled in the BIOS.
Hardware/Software/Workload Configuration
Figure 1 shows the hardware setup diagram for the server host below. We used Ubuntu 14.04.1 with Docker 1.5 for all our experiments. While running Docker configuration, we use bridged networking and host volumes for storing the database.
Figure 1. Hardware/software configuration
Performance Results
We ran 16 instances of DVD Store, where each instance was running an Apache web server, PHP application logic, and a PostgreSQL database. In the Docker cases, we ran one instance of DVD Store per Docker container. In the non-Docker cases, we used the Virtual Hosts functionality of Apache to run many instances of a Web server listening on different ports. We also used the PostgreSQL command line to create different instances of the database server listening on different ports. In the VM-based experiments, we partitioned the host hardware between 8 VMs, where each VM ran 2 DVD Store instances. The 8 VMs exactly committed the CPUs, and under-committed the memory.
The four configurations for our experiments are listed below.
Configurations:
- Native-16S: 16 instances of DVD Store running natively (16 separate instances of Apache 2 using virtual hosts and 16 separate instances of PostgreSQL database)
- Native-Docker-16S: 16 Docker containers running on a native machine with each running one instance of DVD Store.
- VM-8VMs-16S: Eight 4-vCPU VMs each running 2 DVD Store instances
- VM-Docker-8VMs-16S: Eight 4-vCPU VMs each running 2 Docker containers, where each Docker container is running one instance of DVD Store
We ran the DVD Store benchmark for the 4 configurations using 16 client drivers, where each driver process was running 4 threads. The results for these 4 configurations are shown in the figure below.
Figure 2. DVD Store performance for different configurations
In the chart above, the y-axis shows the aggregate DVD Store performance metric orders per minute (OPM) for all 16 instances. We have normalized the order per minute results with respect to the native configuration where we saw about 126k orders per minute. From the chart, we see that, the VM configurations achieve higher throughput compared to the corresponding native configurations. As in the case of prior blogs, this is due to better NUMA-aware scheduling in vSphere. We can also see that running Docker containers either natively or in VMs adds little overhead (2-4%).
To find out why the native configurations were not doing better, we pinned half of the Docker containers to one NUMA node and half to the other. The DVD Store aggregate OPM improved as a result and as expected, we were seeing slightly better than the VM configuration. However, manually pinning processes to cores or sockets is usually not a recommended practice because it is error-prone and can, in general, lead to unexpected or suboptimal results.
Summary
In this blog, we showed that running a PostgreSQL transactional database in a Docker container in a vSphere VM adds very little performance cost compared to running directly in the VM. We also find that running Docker containers in a set of 8 VMs achieves slightly better throughput than running the same Docker containers natively with an out-of-the-box configuration. This is a further proof that VMs and Docker containers are truly “better together.”