MySQL replication performance is a topic that requires no special introduction. Replication was never designed to be extremely fast and there isn't a single MySQL DBA who wouldn't learn it the hard way.
Today, with the improvements introduced in MySQL 5.7, as well as a complete re-implementation done by Amazon Aurora, it seems like we can finally see the light at the end of this very long tunnel.
Let's take both products for a spin and see how they behave. Introduction Before we get busy with the benchmarks, let's quickly explain why MySQL 5.7 and Amazon Aurora are so special. I wouldn't spend a weekend testing them if they weren't, right? MySQL MySQL 5.7 finally uses multi-threaded slave (MTS) implementation that makes sense. Long story short: instead of doing poor man's multithreading that requires you to split your data into multiple schemas (and doesn't guarantee consistency for cross-schema modifications), it can simply replay …

When using a multi-threaded slave, the STOP SLAVE command could take a long time to return because the slave waited for workers to catch up processing the queue. This blog post is about improvements that have been made in MySQL 5.6.26 and later to ensure that STOP SLAVE returns quickly when using a multi-threaded slave (MTS).…

In a few different places I saw comments about my last blog post about references and performance where commentators noted that my example was pointless. Which of course is true and to some degree the point.

I read a lot of PHP code and from time to time I see people with a non-PHP background (or otherwise influenced) putting references everywhere they pass arrays or such in order to prevent copies. I knew this was a bad practice in PHP 5 and wanted to verify this in PHP 7. For readers with a stronger PHP background this doesn't come to mind and so comments are like "what if I want to modify the data?" which might lead to something like this:

function modify(&$data) {
    $data["foo"] = "bar";
}
$data = [ /* huuuuuge array */ ];
modify($data);

In this code, from a performance perspective, the reference likely …

I'm known for telling "Don't use references" (also as video) as those cause different problems (i.e. with foreach) and hurt performance. The reason for the performance loss is that references disable copy-on-write while most places in PHP assume copy-on-write. Meanwhile we have PHP 7. In PHP 7 the internal variable handling changed a lot among other things the reference counting moved from the zval, the container representing a variable, to the actual element. So I decided to run a little test to verify my performance assumption was still valid.

In my test code I'm calling a function which calls strlen (one of the cheapest functions in PHP - PHP strings …

The main schedule for the Percona Live Data Performance Conference is available. Almost everything has been defined. There are tutorials and plenty of sessions waiting for conference attendees.

One thing that is still undefined is the session of lightning talks. The …

I've ran a simple test to see the performance impact of TLS on MySQL connections with MySQL Connector/Python

The test results are in this Jupyter notebook.

TL;DR:

• Try to reuse connections if you use TLS
• Establishing TLS connections is expensive (server & client)
• Improved performance might be possible in the future by using TLS Tickets

Not tested:

• Difference between YaSSL and OpenSSL
• Difference between Ciphersuites
• Performance of larger resultsets and queries

Too often developers and DBAs struggle to pinpoint the root cause of MySQL database performance issues, and then spend too much time in trying to fix them. Wouldn’t it be great to bypass wasted guesswork and get right to the issue?

In our upcoming webinar Tired of MySQL Making You Wait? we’re going to help you discover how to significantly increase the performance of your applications and reduce database response time.

In this webinar, Principal Architect Alexander Rubin and Database Evangelist Janis Griffin will provide the key steps needed to identify, prioritize, and improve query performance.

They will discuss the following topics:

• Wait time analytics using …

The source of this post is in this gist on nbviewer.

After reading about the difference between MySQL Connector/Python and MySQLdb on this blog post I wondered how the C Extension option in Connector/Python would perform.

If you want to run the code yourself you'll need: Jupyter/IPython, Python 3, Requests, MySQLdb, Connector/Python, Matplotlib, Pandas and MySQL.

In [1]:

%matplotlib notebook

In [2]:

import random
import gzip
import time

import pandas as pd
import matplotlib.pyplot as plt
import requests
import mysql.connector
import MySQLdb
for imp in [mysql.connector, MySQLdb]:
    print('Using {imp} {version}'.format(imp=imp.__name__, version=imp.__version__))
print('C Extension for …

I lost count of the number of times I had customers come to me for a regular MySQL performance check-up saying “no, we don’t have any performance problems right now”, just to find they do actually have them, they’re just not aware of it. It’s no big surprise this happens when you’re not using your system as actively as your users are.

So let me share with you one trick I’m using to quickly check if the system I’m on has any problems that need troubleshooting. Actually, it’s dead simple. And no, it’s not a slow query log, it’s Threads_running. Let me show you.

Wait, what’s wrong with the slow query log?

Nothing at all. MySQL’s slow query log is a great tool when you’re looking for slow queries. Or when you’re fishing for things to optimize – either to reduce the resource consumption, or to increase speed for queries you didn’t know are slow.

And it’s …

When MySQL becomes too slow (or too unstable), temptation usually is to tweak the MySQL configuration file. Indeed, it’s a good place to start. But if you ever looked at the available configuration options, you know things can get messy – MySQL now has over 450 configuration variables for your consideration, that are not classified in any way, and neither of them are included in the stock my.cnf. It’s hard to know where to start!

I’m hoping that this blog post will help you overcome the anxiety of tuning MySQL, whether you’re setting up a new server, or tuning an already running server for better performance.

Don’t do it the way rookies do it

During the last 9 years I’ve spent at Percona working as a MySQL performance and scalability consultant, I found that customers often use the trial and error approach when tuning MySQL configuration: they change a few things and check if it …