Showing entries 1 to 10 of 65
10 Older Entries »
Displaying posts with tag: Benchmarking (reset)
MySQL 8.2.0 Community vs. Enterprise; Is There a Winner?

To be honest, the comparison between the two MySQL distributions is not something that excited me a lot. Mainly because from my MySQL memories, I knew that there is not a real difference between the two distributions when talking about the code base.To my knowledge the differences in the enterprise version are in the additional […]

How to Benchmark Replication Performance in MySQL

In this blog, I will cover important aspects which you need to test when benchmarking replication setup. MySQL has great tools that could be used to test its performance. They include:

sysbench – https://github.com/akopytov/sysbench

BMK-kit – http://dimitrik.free.fr/blog/posts/mysql-perf-bmk-kit.html

mysqlslap – https://dev.mysql.com/doc/refman/8.0/en/mysqlslap.html

LinkBench – https://github.com/facebookarchive/linkbench

I will not describe how to use them here, as you can find instructions on the provided links or in the Percona blog by browsing tags …

[Read more]
Measuring the Impact of Dynimize on Your MySQL Workload

While it's easier to measure the impact of Dynimize if you are running a MySQL benchmark with clear metrics, it can sometimes be a challenge on a production workload where you don't have precise performance analytics or metrics available. There are many great MySQL performance analysis tools out there, however they can often take time and effort to setup.

The simple measureDyniMysql script was created for this exact reason, and does not incur any MySQL downtime. You can find it at /opt/dynimize/measureDyniMysql after installing Dynimize. It will report the change in MySQL queries per second and mysqld CPU usage after applying Dynimize. Here is how to use it.


1. Install and start dynimize, and get your mysqld process into the dynimized state. For example, the …

[Read more]
Antijoin in MySQL 8

In MySQL 8.0.17, we made an observation in the well-known TPC-H benchmark for one particular query. The query was executing 20% faster than in MySQL 8.0.16. This improvement is because of the “antijoin” optimization which I implemented. Here is its short mention in the release notes:

“The optimizer now transforms a WHERE condition having NOT IN (subquery), NOT EXISTS (subquery), IN (subquery) IS NOT TRUE, or EXISTS (subquery) IS NOT TRUE internally into an antijoin, thus removing the subquery.”

Facebook Twitter LinkedIn

MySQL with Docker – Performance characteristics

Docker presents new levels of portability and ease of use when it comes to deploying systems. We have for some time now released Dockerfiles and scripts for MySQL products, and are not surprised by it steadily gaining traction in the development community.…

AWS Aurora Benchmarking part 2

Some time ago, I published the article on AWS Aurora Benchmarking (AWS Aurora Benchmarking – Blast or Splash?), in which I analyzed the behavior of different solutions using synchronous replication in AWS environment. This blog follows up with some of the comments and suggestions I received regarding that post from the community and Amazon engineers.

I decided to perform another round of tests, keeping in mind comments and suggestions received.

I presented some of the results during the Percona conference in Santa Clara last April 2016. The following is the transposition that presentation, with more details.

Not interested in the preliminary descriptions? Go to the results section

Why new tests?

[Read more]
MySQL 5.7 Labs — Using Loopback Fast Path With Windows 8/2012

TCP Loopback fast path

In Windows 8 and Windows server 2012, Microsoft introduced a new “TCP Loopback fast path” feature (see the Microsoft Technet article: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path).…

Performance Schema: Great Power Comes Without Great Cost

Performance Schema is used extensively both internally and within the MySQL community, and I expect even more usage with the new SYS Schema and the Performance Schema enhancements in 5.7. Performance Schema is the single best tool available for monitoring MySQL Server internals and execution details at a lower level. Having said that, we are also no stranger to the fact that any monitoring tool comes with an additional cost to performance. Hence It has always been an important question to find out just how much it costs us when Performance …

[Read more]
Performance Impact of InnoDB Transaction Isolation Modes in MySQL 5.7

During the process of reviewing our server defaults for MySQL 5.7, we thought that it might be better to change the default transaction isolation level from REPEATABLE-READ to READ-COMMITTED (the default for PostgreSQL, Oracle, and SQL Server). After some benchmarking, however, it seems that we should stick with REPEATABLE-READ as the default for now.

It’s very easy to modify the default isolation level, however, and it can even be done at the SESSION level. For the most optimal performance you can change the transaction isolation level dynamically in your SESSION according …

[Read more]
Is MySQL’s innodb_file_per_table slowing you down?

MySQL’s innodb_file_per_table is a wonderful thing – most of the time. Having every table use its own .ibd file allows you to easily reclaim space when dropping or truncating tables. But in some use cases, it may cause significant performance issues.

Many of you in the audience are responsible for running automated tests on your codebase before deploying to production. If you are, then one of your goals is having tests run as quickly as possible so you can run them as frequently as possible. Often times you can change specific settings in your test environment that don’t affect the outcome of the test, but do improve throughput. This post discusses how innodb_file_per_table is one of those settings.

I recently spoke with a customer whose use case involved creating hundreds of tables on up to 16 schemas …

[Read more]
Showing entries 1 to 10 of 65
10 Older Entries »