Feed Aggregator

Table of Contents

• Database Benchmark
• General Benchmarking Tools
• CPU Benchmarking
• Disk benchmarking
• Network Benchmarking
  • Tools
• Application Stress Testing
  • OwnCloud / NextCloud
  • Asterisk

Database Benchmark

• sysbench (filesystems and OS/HW tests), Sysbench source, sysbench v0.5, sysbench scripts
• OSDL Database Test Suite (download)
• DBT2 (TPC-C, OLTP), DBT2 Benchmark Tool for MySQL
• DBT3 (TPC-H, complex and long running queries, data warehouse (DWH))
• TM1 (3^rd party, ODBC, telecom benchmark)
• TPC Benchmarks
• TPCC-mysql
• db_STRESS
• HammerDB
• db_bench
• Acronis perfkit (benchmark, benchmark-db)
• Web3Bench (TiDB, MySQL written in Java/Python)
• Finch (Finch is a MySQL benchmark tool developed for software engineers and modern infrastructures.)

General Benchmarking Tools

• Apache JMeter: To test performance on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more).
• Gatling: Gatling is a highly capable load testing tool. It is designed for ease of use, …

One of the big advantages of MySQL is its concept of Pluggable Storage Engines. This means you can choose the most optimal Storage Engine for your needs. This also has a disadvantage: You have to know what you are doing…

If you need some help deciding which is the right Storage Engine or even strategy for you or if you want us to make an independent and vendor neutral comparison of those Storage Engines consider our FromDual Consulting Services!

MySQL provides the following storage engines:

mysql> SHOW ENGINES;

+------------+----------+-------------------------------------------------------+
| Engine     | Support  | Comment                                               |
+------------+----------+-------------------------------------------------------+
| ARCHIVE    | YES      | Archive storage engine                                |
| BerkeleyDB | NO       | Transactional storage engine with page-level locking  |
| BLACKHOLE  | YES      | /dev/null storage engine for replication transmission |
| …

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Ivan

Thanks a lot for your wishes!

Indeed it started very interesting yet… :)

Oli

[http://www.blogger.com/profile/04013184952866618726 Ivan] said…

Oli!

I wish you all the best and good luck!

I am sure that this new adventure will give you lots of gratification.

Cheers, -ivan

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hello Henrik,

Thank you very much for your wishes and all you have done already!

Oli

[http://www.blogger.com/profile/09201666166374161923 hingo] said…

Hi Oli

I wish you all the best in taking this step, and promise to do all I can to help you!

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Ronald, hi Fortxun,

Thank you very much for your wishes. I hope we will meet once in a while (again)…

Oli

[http://www.blogger.com/profile/13150580805698500214 Fortxun] said…

Excellent, good luck!.

[http://www.blogger.com/profile/16170615042077930093 Ronald Bradford] said…

Congrats Oli.

I hope you have a very prosperous business!

Hello everybody,

One month earlier than planned we have the great pleasure to announce you that the company called FromDual goes operational today!

We are excited about this step and it is an new era in our personal evolution to get back in full-contact with customers and solve their real life day-to-day MySQL problems.

So we are happy hearing from you and to help you solving your individual MySQL problems…

You can find us at FromDual or you can drop us a line.

Regards,
Oli Sennhauser (aka Shinguz)
Senior MySQL Consultant at FromDual

About FromDual

FromDual provides neutral and vendor independent MySQL consulting, training and other services around MySQL and its derivatives. The company concentrates on the individual needs of its customers and achieves, in a close co-operation the best results for their problems.

Our consultants have been working in many projects in Europe. We were involved in small start-ups, medium size enterprises and huge world wide operating top-500 companies and solved their …

Hello everybody,

One month earlier than planned we have the great pleasure to announce you that the company called FromDual goes operational today!

We are excited about this step and it is an new era in our personal evolution to get back in full-contact with customers and solve their real life day-to-day MySQL problems.

So we are happy hearing from you and to help you solving your individual MySQL problems…

You can find us at FromDual or you can contact us here.

Regards,
Oli Sennhauser (aka Shinguz)
Senior MySQL Consultant at FromDual

About FromDual

FromDual provides neutral and vendor independent MySQL consulting, training and other services around MySQL and its derivatives. The company concentrates on the individual needs of its customers and achieves, in a close co-operation the best results for their problems.

Our consultants have been working in many projects in Europe. We were involved in small start-ups, medium size enterprises and huge world wide operating top-500 companies and solved their …

The following presentations are available:

[http://www.blogger.com/profile/16041515498065869604 qu1j0t3] said…

ZFS can prevent corruption from ever reaching MySQL (or any application).

For mission critical data I wouldn’t use anything else.

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hi Shlomi,

Thanks a lot for your input!

I am not a security specialist so I do not know what those guys who implement audit solutions think about your approach. But I can imagine that moving login information away immediately gives less possibilities to manipulate those data.

But as SUPER users are not logged it is halve baked anyway.

Using your approach in combination with the federated or federatedX Storage Engine would give again the possibility to store the information remote.

Regards, Oli

[http://www.blogger.com/profile/11874165719204714241 Shlomi N.] said…

Hi, This is a cool hack! One can simplify it by not writing to the error log but to some internal log table, in which case you can use a normal stored function, no need for UTF.

To complicate the simplification: You can later on purge rows from that log file and do stuff with, like appending them to the error log, using external script.

Problem

A customer recently showed up with the following problem:

*With your guidelines
[ 1
] I am now able to send the MySQL error log to the syslog and in particular to an external log server.
But I cannot see which user connects to the database in the error log.

How can I achieve this?*

Idea

During night when I slept my brain worked independently on this problem and in the morning he had prepared a possible solution for it.

What came out is the following:

• We create an UDF which allows an application to write to the MySQL error log.
  See my previous article about this
  [ 2
  ].
• We specify in a simple SQL query how the string should look which we want to write to the MySQL error log file.
• We use the init_connect
  [ 3
  ] hook (= logon trigger) which MySQL provides to log the information to the error log.

How to solve it?

The UDF can be taken from
[ 4
]. Be not confused by the version number. It just worked with MySQL 5.1.42. Load the UDF according to the article into the MySQL database. Follow the little example …

[http://www.blogger.com/profile/05445777885744635565 Jo] said…

I wrote an interesting UDF you may be interested. JsMap - running JavaScript in MySQL

Today a customer with corrupted data files showed up. When we enquired a bit more he told us that he had a broken I/O controller. This is one of the worst things which can happen to you!

The reason is the following: When a I/O controller starts to die it often does not happen immediately. The controller dies slowly producing more and more corrupt data. When you just write data without checking or reading them it can take days or even weeks until you discover the problem.

But the nasty thing is, that even your backup is infected with the corrupted data. In worst case corruption started long before your oldest still existing backup was made.

Fortunately DBMS are a bit sensitive related to data corruptions and start to complain pretty early. So please consider warning or error messages about data corruption as serious and try to find the problem immediately and solve it!

What can we do against spreading data corruption?

• Monitor logs (syslog, database error log, application log, etc.).
• Ideally do physical AND …

[http://www.blogger.com/profile/11195863756524022642 Shinguz] said…

Hello kabel,

Thanks for the flowers!

Anyhow, logical backups with such an amount of data is nearly impossible to restore (in a timely manner)!

But if you rely on physical backup methods you do not get rid of the corruption. So one is trapped in this situation. :-(

Do you have an idea why you got the corruptions? Playing around with DRBD or anything similar on file system level? Or just upgraded to 5.1? How does the corruption manifests?

Regards, Oli

[http://www.blogger.com/profile/08993510241119917712 kabel] said…

Wow. This post could not have been more timely. I have a (legacy) server with a large (600G) InnoDB tablespace that is slightly corrupted. A new machine has been rotated into production while I clean up this monster, but you just saved me a lot of heartache with the fatal lock timeout catch. It’s probably going to end up being a incremental table dump and restore.

Thanks!