Now that docker has hit the "production" ready milestone I decided to re-run some performance tests to see if anything has changed in terms of overall docker performance, especially MySQL performance inside of a container. Previously Docker was considered "not production ready". That still might be the case, but I wanted to update this page with some newer Docker tests.

I'm running these tests on a Storm Dedicated Server with an E3-1220V2, 8GB RAM, 2 x 240GB SSDs in Raid 1. I am using Ubuntu 14.04 for the OS. This is a virtual server that is dedicated entirely to me, so there are no other instances on the server. There will be a slight performance hit as KVM does reduce performance, but then again you don't really want to be running docker containers without some sort of isolation, at least publicly available Docker deployments.

I'm using Percona 5.6 for these tests. I am using the same installation method on the host, and inside of the docker container.

DOCKER 1.0.1 Setup and ConfigInitially I created a single container and ran both MySQL and Sysbench inside the same container. Many will say that this is pointless and not a use case for Docker. I agree, but I still wanted to test as many different ways as possible. I created another container that just contained Sysbench, which connected to the MySQL container to create a more "real world" type of test.

The Blue column results are from a virtualized instance on top of KVM. This is exactly how most people currently use MySQL, in a virtualized environment. I ran Sysbench on the same host, so both MySQL and Sysbench were using the same resources.

The Orange column results were recorded from inside a Docker container on the same virtualized instances as the blue test run. I used Percona 5.6 with the same my.cnf settings as before, and I ran Sysbench inside of the container as well. I stopped MySQL on the host before running the tests inside of the container.

The Yellow column results were recorded from a second container, which just had sysbench installed in it. I then connected to a "remote" database IP, which was the IP from the first container, which has Percona 5.6 running. This simulates a more "real world" use case, however the networking performance would be a lot worse if I was connecting from a different host. Regardless, Docker didn't kill performance all that much as you can see from the results.

This container is meant for some basic benchmarking using Sysbench. For this example I am using CentOS on the host and in the container. The first step is to install Docker, and pull down the image we want to use.

I decided to run some basic performance tests for MySQL to see if there was a huge difference in performance between running MySQL inside a Docker container and outside of a container, as you normally would on a VPS / Dedicated server.

The main goal is to determine how much of a performance overhead Docker adds to the application. I will be using Sysbench 0.4.12 to test MySQL performance. I will be running the client both locally (on the same vps that MySQL is running) as well as remotely, from another VPS connecting via Private Network.

I Ran 5 different configurations to try and test all of the possible combinations for connecting to MySQL. The first two results are run on an 8GB Storm VPS. Sysbench was run on the same host that the MySQL DB was on for the first test (L). I created another 8GB VPS and connected both VPS via private Network for the second test. Sysbench was ran on the 2nd VPS and connected to MySQL on the first VPS (R).

For the docker tests, I used the same VPS. I created a docker container using the CentOS image from the Docker Index. Info on the container is listed above. The first test involved running Sysbench and MySQL inside the same container (LI). The second test involved running MySQL inside the container, but running Sysbench from outside the container, but on the same VPS (LO). The last test involved running MySQL inside the container on the first VPS, then running Sysbench on the second VPS, connecting remotely (RO).

8GB VPS Sysbench run locally (L)

8GB VPS Sysbench run remotely on another 8GB VPS (R)

8GB VPS + Docker Sysbench run inside same container (LI)

8GB VPS + Docker Sysbench run outside container, same host (LO)

8GB VPS + Docker Sysbench run from remote host (RO)

I used the following command to test performance. I ran each test 5 times and averaged the results accross 5 runs. I used 1,4,8,16 threads, again, each time I recorded the results from 5 runs. I also used --oltp-read-only for the last read only test.

As you can see, there is a pretty large performance overhead with MySQL. This could just be due to the fact that I am already running MySQL on a VPS, however Docker clearly does reduce performance by a notable amount. This is for the 0.9 release, so it will be interesting to see how performance changes down the road.

Below is an example of a simple for loop that will create 3 Docker containers that are running Percona 5.6. Replace "galera_main:latest bash" with the build you want to use, and replace "bash" with whatever you want the containers to actually run. Obviously in this case we would probably want MySQL to run, however if you still need to do some fine tuning and want to mess around in the container, using bash is the best option.

If you want to save the current state of a container you can use the commit command to save the container, so that you can roll back later on if you want to, or you can use the committed container to build off of.

This is based off of a slightly modified version of the guide above. I ran into a few issues when following that guide, so I am posting a different method here. I'm using Ubuntu 14.04 instead of 12.04 because new and shiny things are always better.

You could just use a docker file for all of this, but for now I am covering the manual steps for people who have not really used docker before. This command will pull down the latest version of Ubuntu and will start bash. NOTE Once this command finishes you will be placed inside of the container.

docker run -i -t ubuntu:latest bash

Now that we are in the container, we are going to run updates just because. We are also going to add Percona repos, grab a key and then install the stuff we need to Percona.

After we get everything installed, we need to replace / update the my.cnf. Use the example listed below. I've already entered in some IPs, read below to see what needs to be replaced for your cluster. It is ok if you don't know the other two container IPs yet, so if you have not created more than one container you still want to paste in the contents of this file, we will update it later on.

At this point you can re-enter each container, and update the my.cnf file with the IPs listed. Enter each container, update the file, then exit using Ctrl+p then Ctrl+q. You might as well commit each container at this point. Usually it's better to commit too often than not at all.

On the first node Attach to the container, and then run the bootstrap for mysql cluster

/etc/init.d/mysql bootstrap-pxc

On the first node Once the server has started, we need to make a user for replication, we should also make sure the other two containers can connect. Replace the IPs used below with whatever the other two containers are using.

On the other two nodes Attach to the container, and start up MySQL in each container. If you get any failed starts, make sure the my.cnf file is correct on all 3 nodes (sometimes paste fails cause a lot of headaches). If my.cnf looks ok, you may want to apt-get install telnet on each container, then attempt to telnet to each container to make sure you can actually connect.

service mysql start

On the first node If the other two containers started up correctly, and the config files were edited correctly, you should see a cluster size of 3 on the "master node" or in this case the "original" node.