Introduction

This page shows the results for benchmarking the following configuration:

• MariaDB 5.3.2 + MyISAM
• MariaDB 5.5.18 + MyISAM
• MySQL 5.5.19 + MyISAM
• MySQL 5.6.4 + MyISAM

The test is performed using the automation script /mariadb-tools/dbt3_benchmark/launcher.pl.

Details about this automation script can be found on the DBT3 automation scripts page.

Hardware

The tests were performed on our facebook-maria1 machine. It has the following parameters:

• CPU: 16 Intel® Xeon® CPU L5520 @ 2.27GHz
• Memory: Limited to 16 GB out of 72 by adding 'mem=16G' parameter to /boot/grub/menu.lst
• Logical disk: HDD 2 TB
• Operating system:

Scale factor 30

This test was performed with the following parameters:

• Scale factor: 30
• Query timeout: 2 hours
• Number of tests per query: 1
• Total DB size on disk: about 50GB
• Available memory: 16 GB

NOTE: The available memory is controlled by a parameter mem=16G added to the file /boot/grub/menu.lst

Steps to reproduce

Follow the instructions in DBT3 automation scripts to prepare the environment for the test.

Before you run the test, ensure that the settings in the test configuration files match your prepared environment. For more details on the test configuration, please, refer to the Test configuration parameters.

After the environment is prepared, the following command should be executed in the shell:

perl launcher.pl \
--results-output-dir=/home/mariadb/benchmark/dbt3/results/myisam_test \
--project-home=/home/mariadb/benchmark/dbt3/ \
--datadir=/home/mariadb/benchmark/dbt3/db_data/ \
--test=./tests/myisam_test_mariadb_5_3_mysql_5_5_mysql_5_6.conf \
--queries-home=/home/mariadb/benchmark/dbt3/gen_query/ --scale-factor=30 \
--TIMEOUT=7200

Compared configurations

The following configurations have been compared in this test:

Case 1: MariaDB 5.3.2 + MyISAM

Here are the common options that the mysqld server was started with:

net_read_timeout = 300
net_write_timeout = 600
key_buffer_size = 3G
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
table_open_cache = 1024
thread_cache = 512
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
max_connections = 256
query_cache_size = 0
query_cache_type = 0
sql-mode = NO_ENGINE_SUBSTITUTION

#Per-test optimizations
optimizer_switch='index_merge=on'
optimizer_switch='index_merge_union=on'
optimizer_switch='index_merge_sort_union=on'
optimizer_switch='index_merge_intersection=on'
optimizer_switch='index_merge_sort_intersection=off'
optimizer_switch='index_condition_pushdown=on'
optimizer_switch='derived_merge=on'
optimizer_switch='derived_with_keys=on'
optimizer_switch='firstmatch=off'
optimizer_switch='loosescan=off'
optimizer_switch='materialization=on'
optimizer_switch='in_to_exists=on'
optimizer_switch='semijoin=on'
optimizer_switch='partial_match_rowid_merge=on'
optimizer_switch='partial_match_table_scan=on'
optimizer_switch='subquery_cache=off'
optimizer_switch='mrr=on'
optimizer_switch='mrr_cost_based=off'
optimizer_switch='mrr_sort_keys=on'
optimizer_switch='outer_join_with_cache=on'
optimizer_switch='semijoin_with_cache=off'
optimizer_switch='join_cache_incremental=on'
optimizer_switch='join_cache_hashed=on'
optimizer_switch='join_cache_bka=on'
optimizer_switch='optimize_join_buffer_size=on'
optimizer_switch='table_elimination=on'

join_buffer_space_limit = 3072M
join_buffer_size = 1536M
join_cache_level = 6
mrr_buffer_size = 96M
tmp_table_size = 96M
max_heap_table_size = 96M

Case 2: MariaDB 5.5.18 + MyISAM

Uses the same configuration file as MariaDB 5.3.2 in Case 1.

Case 3: MySQL 5.5.19 + MyISAM

Here are the common options that the mysqld server was started with:

net_read_timeout = 300
net_write_timeout = 600
key_buffer_size = 3G
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
table_open_cache = 1024
thread_cache = 512
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
myisam_sort_buffer_size = 8M
max_connections = 256
query_cache_size = 0
query_cache_type = 0
sql-mode = NO_ENGINE_SUBSTITUTION

join_buffer_size = 1536M
tmp_table_size = 96M
max_heap_table_size = 96M
read_rnd_buffer_size = 96M

Case 4: MySQL 5.6.4 + MyISAM

Here are the common options that the mysqld server was started with:

net_read_timeout = 300
net_write_timeout = 600
key_buffer_size = 3G
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
table_open_cache = 1024
thread_cache = 512
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
myisam_sort_buffer_size = 8M
max_connections = 256
query_cache_size = 0
query_cache_type = 0
sql-mode = NO_ENGINE_SUBSTITUTION

optimizer_switch='mrr=on'
optimizer_switch='mrr_cost_based=off'
optimizer_switch='batched_key_access=on'
optimizer_switch='index_condition_pushdown=on'

join_buffer_size = 1536M
tmp_table_size = 96M
max_heap_table_size = 96M
read_rnd_buffer_size = 96M

The server has been restarted between each query run and the caches have been cleared between each query run.

Results (without q20)

Here is the graphics of the results:

(Smaller bars are better)

NOTE: Queries that are cut off by the graphics have timed out the period of 2 hours.

Here are the actual results in seconds (smaller is better):

NOTE: The columns named "Ratio" are calculated values of the ratio between the current value compared to the value in the first test configuration. The formula for it is (current_value/value_in_first_row). For example if MariaDB 5.3.2 (the first column) handles a query for 100 seconds and MySQL 5.6.4 (the last configuration) handles the same query for 120 seconds, the ratio will be 120/100 = 1.20. This means that it takes MySQL 5.6.4 20% more time to handle the same query.

The archived folder with all the results and details for that benchmark can be downloaded from here: MyISAM s30 on facebook-maria1

Notes

Queries 2-opt.sql and 18-opt.sql are tested only for MariaDB 5.3.2 and MariaDB 5.5.18

• Additional startup parameters for 2_opt:

  --optimizer_switch='mrr_sort_keys=off'
  

• Additional startup parameters for 18_opt:

  --optimizer_switch='semijoin=off' --optimizer_switch='index_condition_pushdown=on'
  

• Additional modifications for 17-opt1:

  select
  sum(l_extendedprice) / 7.0 as avg_yearly
  from
    part straight_join lineitem
  where
  p_partkey = l_partkey
  ...
  

• Additional modifications for 17-opt2:

  select
   	sum(l_extendedprice) / 7.0 as avg_yearly
  from
   	lineitem straight_join part
  where
   	p_partkey = l_partkey
  ...
  

• Additional modifications for 19-opt1:

  select
   	sum(l_extendedprice* (1 - l_discount)) as revenue
  from
   	part straight_join lineitem
  where
   	(
   		p_partkey = l_partkey
  ...
  

• Additional modifications for 19-opt2:

  select
   	sum(l_extendedprice* (1 - l_discount)) as revenue
  from
   	lineitem straight_join part
  where
   	(
   		p_partkey = l_partkey
  ...
  

Benchmark for q20

This benchmarked only q20 with the same settings as described above for the other queries. The only difference is the timeout that was used: 30000 seconds (8 hours and 20 min).

Compared cases

The benchmark for q20 compares the following cases:

• q20.sql - the original query is run with the IN-TO-EXISTS strategy for all servers. The following optimizer switches were used for MariaDB:

  --optimizer_switch='in_to_exists=on,materialization=off,semijoin=off';
  

• q20-opt0.sql - the original query is changed so that the same join order is chosen as for the two subsequent variants that test materialization where this order is optimal. The join order is:

  select s_name, s_address
   from supplier, nation
   where s_suppkey in (select distinct (ps_suppkey)
                       from '''part straight_join partsupp'''
                       where ps_partkey = p_partkey ...
  

• Since the IN-TO-EXISTS strategy is essentially the same for both MariaDB and MySQL, this query was tested for MySQL only.

• q20-opt1.sql - modifies the original query in two ways:
  • enforces the MATERIALIZATION strategy, and
  • enforces an optimal JOIN order via straight_join as follows:

    select s_name, s_address
     from supplier, nation
     where s_suppkey in (select distinct (ps_suppkey)
                         from '''part straight_join partsupp'''
                         where ps_partkey = p_partkey ...
    

q20-opt1.sql uses the following optimizer switches for MariaDB:

--optimizer_switch='in_to_exists=off,materialization=on,semijoin=off';

• q20-opt2.sql - the same as q20-opt1.sql but allows the optimizer to choose the subquery strategy via the following switch:

  --optimizer_switch='in_to_exists=on,materialization=on,semijoin=on';
  

• This switch results in the choice of SJ-MATERIALIZATION.

NOTE: For MySQL there are no such optimizer-switch parameters, and the tests were started without any additional startup parameters. The default algorithm in MySQL is in_to_exists.

Results for q20

Here is the graphics of the results of the benchmarked q20: (Smaller bars are better)

NOTE: Queries that are cut off by the graphics have timed out the period of 30000 seconds.

Here are the actual results in seconds (smaller is better):