In this blog post, I’ll discuss changes I’ve made to the

tpcc-mysql

 benchmark tool. These changes make it less random and support multi-schema.

This post might only be interesting to performance researchers. The

tpcc-mysql

 benchmark to is what I use to test different hardware (as an example, see my previous post: https://www.percona.com/blog/2016/07/26/testing-samsung-storage-in-tpcc-mysql-benchmark-percona-server/).

The first change is support for multiple schemas, rather than just one schema. Supporting only one schema creates too much internal locking in MySQL on the same rows or the same index. Locking is fine …

Saturday I was in my favorite grocery store, standing in the line, browsing the net on my phone. I read Vadim Tkachenko‘s blog post about Measuring Percona Server Docker CPU/network overhead and his findings were opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking […]

Saturday I was in my favourite grocery store, standing in the line, browsing the net on my phone. I read Vadim Tkachenko‘s blog post about Measuring Percona Server Docker CPU/network overhead and his findings were the opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking which I didn’t […]

Back in October I have write about possible ways of running multiple MySQL instances on the same hardware. As the months passing by, the project of splitting our database schemas into standalone instances is closing in, so I started to check the different ways.

EDIT: This post is outdated, here is the follow up.

I started with docker, because we’ll use containers anyway with the applications, and I think it is a good idea to minimise the diversity of an infrastructure. I used the docker’s “official” Percona image (it is official by Docker not by Percona!) which is easy to use, and flexible enough. (https://hub.docker.com/_/percona/) This image supports using custom config files, you can mount your …

Back in October I have write about possible ways of running multiple MySQL instances on the same hardware. As the months passing by, the project of splitting our database schemas into standalone instances is closing in, so I started to check the different ways. EDIT: This post is outdated, here is the follow up. I started […]

When you have read my previous blog post about MariaDB 10.1 GA performance, you have probably wondered why I didn’t include any numbers for MySQL 5.7. There are two reasons: first MySQL wasn’t GA at that time and secondly MySQL is not running stable on Power8. Today I will come up with a comparison benchmark. […]

The post MariaDB 10.1 and MySQL 5.7 performance on commodity hardware appeared first on MariaDB.org.

Introduction

The purpose of this test is to benchmark MySQL 5.6 performance on hardware with Haswell CPUs, SSDs and PCIe Flash storage devices.

Background

Software

• SysBench OLTP workload installed on the database machine
  
• MySQL 5.6.24 distribution from Percona
  
• jemalloc used for MySQL Server and Sysbench test client
  
• Charts are plotted using MySQL Performance Analyzer

Method

• Data and software on server was wiped out post every test run.
  
• Predefined number of tables - 16 or 64
  
• Predefined size of rows - 20M per table
  

Tests
Read Only
Read Write
Concurrencies vary from 1 to 512 with incremental increase
EXT4 vs XFS

…

Previously I tested Tokutek’s Fractal Trees (TokuMX & TokuMXse) as MongoDB storage engines – today let’s look into the MySQL area.

I am going to use modified LinkBench in a heavy IO-load.

I compared InnoDB without compression, InnoDB with 8k compression, TokuDB with quicklz compression.
Uncompressed datasize is 115GiB, and cachesize is 12GiB for InnoDB and 8GiB + 4GiB OS cache for TokuDB.

Important to note is that I used tokudb_fanout=128, which is only available in our latest Percona Server release.
I …

One of my goals at Acmebenchmarking is make sure I'm running on hardware that is representative of real-world infrastructure, while at the same time doing it as inexpensively as possible.

To date I've been running on two custom built "desktops" (for lack of a better term). Both have an Intel Core i7 4790K processor (quad core plus hyperthreading, 4Ghz), 32GB RAM (dual channel), and a quality SSD. They are named acmebench01 and acmebench02.

Alas, it is time to expand. MUST...PURCHASE...MORE...HARDWARE!

In order to maintain the inexpensive theme I tend to buy used hardware, my goal on this purchase was to achieve many more cores and greater memory bandwidth than my existing machines can provide. Keep in mind that used hardware is great for benchmarking (and likely development and QA environments) but you might want to avoid it for production. For years now I've been purchasing used hardware …

Technical conferences are flooded with visual [mis]representations of a particular product's performance, compression, cost effectiveness, micro-transactions per flux-capacitor, or whatever two-axis comparison someone dreams up. Lets be honest, benchmarketers like to believe we all suffer from innumeracy.

The Merriam-Webster dictionary defines innumeracy as follows:
innumeracy (noun): marked by an ignorance of mathematics and the scientific approach Mark Callaghan has been a long time advocate of explaining benchmark results, but that's not the point of the bar chart. Oh no, the bar chart only exists to catch your eye and …