MariaDB 5.5.23 Stable (GA) now available

avril 12, 2012
Tags:

Enfin ! 🙂

La branche 5.5 de MariaDB est désormais stable (GA)

y’a plus qu’à…

http://dimitrik.free.fr/blog/archives/2016/02/mysql-performance-scalability-on-oltp_rw-benchmark-with-mysql-57.html

Commentaires fermés sur MariaDB 5.5.23 Stable (GA) now available

MySQL 5.6 rock suite

avril 5, 2012

Voici la suite du post MySQL 5.6 rock, dans lequel je test MySQL 5.5 & 5.6, MariaDB 5.3 & 5.5 et Percona server 5.5.

Pour cet article, toujours un bench. Le contexte est assez proche, à la différence près que cette fois les serveurs sont testés en lecture (65%) et écriture (35%).

 
 
Les règles du bench

sysbench, options read/write complex, 128 connexions concurrentes

Moteur InnoDB, 30 millions de lignes, 6.7 Go de données

Pas de warmup, le disque doit être sollicité au maximum.

Les tests ont été lancé 4 fois sur chaque version, avec restart du serveur entre chaque run.

Les confs sont proche cad les paramètres communs à toutes les versions ont les mêmes valeurs, les autres, leur valeur par défaut

La moyenne donne les résultats suivants:

95 centile (en ms)

    • Percona 5.5.12: 182.135
    • MariaDB 5.3.5 *: 132.3025
    • MariaDB 5.5.20: 183.1275
    • MySQL 5.5.22: 160.8525
    • MySQL 5.6.4: 153.6175

 

dasini.net - 95 centile for R/W i/o bounds

 
 
 

Nombre de transactions par seconde

  • Percona 5.5.12: 2170.5
  • MariaDB 5.3.5 *: 2016.505
  • MariaDB 5.5.20: 2134.9125
  • MySQL 5.5.22: 1680.7525
  • MySQL 5.6.4: 1738.4775

 

dasini.net - TPS for R/W i/o bounds

 
 
 

Mes commentaires

En matière de temps de réponse, MariaDB 5.3 (branche MySQL 5.1 + nombreuses améliorations apportées par Monty Program AB) est sans (trop de) surprises, celui qui donne les meilleurs temps de réponse sur 95 % des meilleurs requêtes (95 centile). Mais il sera moins scalable du fait de son unique Buffer pool.

La bonne surprise vient de MySQL 5.6 où le temps de réponse est significativement meilleur qu’avec la branche 5.5 (de 5 à 15%).

En ce qui concerne débit maximum, les TPS, MySQL est en retrait. Il plafonne aux environs des 1700 TPS alors que MariaDB & Percona dépassent sans souci les 2000 !

Cet écart (20% tout de même !!!) s’explique sans doute par de meilleurs performances d’XtraDB (qui équipe MariaDB & Percona) en matière de débit, par rapport à son cousin InnoDB (XtraDB étant un fork d’innoDB, développé par Percona).

Le produit s’améliore donc, et ce même sans tuning particulier, c’est une très bonne chose !

Ceci dit, l’optimisation du serveur MySQL risque de commencer dès le choix de la distrib, en prenant en compte le workload (lecture seule, écriture seule, lecture+écriture), le besoin (temps de réponse, débit maximal), …

Avoir dans son équipe un profile MySQL expérimenté devient de plus en plus nécessaire. Et ça je trouve que c’est plutôt une bonne chose 😉

 
 
 

Divers

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=40000000 \
--oltp-test-mode=complex --max-requests=0 --max-time=600 \
--num-threads=128

innodb_buffer_pool_instances    4 (1 pour MariaDB 5.3)
innodb_buffer_pool_size    34359738368
innodb_doublewrite    ON
innodb_file_per_table    ON
innodb_flush_log_at_trx_commit    2
innodb_log_buffer_size    8388608
innodb_log_file_size    152043520
innodb_log_files_in_group    2
innodb_version  1.1.8-24.1 / 1.2.4 (ou XtraDB 1.1.6-20.1)

general_log    OFF
log_bin    OFF
slow_query_log    OFF

 

         
           Name: sbtest
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 30000237
 Avg_row_length: 224
    Data_length: 6741295104
Max_data_length: 0
   Index_length: 477085696
      Data_free: 6291456
 Auto_increment: 33800371
    Create_time: 2012-03-29 18:42:34
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_swedish_ci
3

MySQL 5.6 rock !

mars 30, 2012

Encore un bench (c’est la saison :))

Comme d’habitude, mon but n’est pas de connaître les possibilités maximales du serveur (d’autres le font mieux que moi), mais plutôt d’avoir une idée assez précise de leurs comportements respectifs dans un environnement le plus proche possible de ma prod.

Pour ce test, les candidats sont, Percona 5.5, MariaDB 5.3 & 5.5, MySQL 5.5 et la dernière milestone de MySQL 5.6. L’idée est de voir comment se comporte les différentes versions dans un contexte I/O bounds ie un faible hit ratio du buffer pool (ou du moins le plus bas possible), en d’autres termes, simuler le comportement du serveur MySQL dans un environnement où la quantité de données est énorme (comme à Viadeo).

 

Les règles du bench

sysbench, options read only complex, 128 connexions concurrentes

Moteur InnoDB, 30 millions de lignes, 6.7 Go de données

Pas de warmup, le disque doit être sollicité au maximum.

Les tests ont été lancé 10 fois sur chaque version, avec restart du serveur entre chaque run.

Les confs sont proche cad les paramètres communs à toutes les versions ont les mêmes valeurs, les autres, leur valeur par défaut

 

La moyenne donne les résultats suivants:

95 centile (en ms)

    • Percona 5.5.12: 101.142
    • MariaDB 5.3.5 *: 94.926
    • MariaDB 5.5.20: 104.02
    • MySQL 5.5.22: 103.644
    • MySQL 5.6.4: 66.586

 

dasini.net - 95 centile

Ce que je trouve intéressant dans ces résultats:

Les 3 versions de la branche 5.5 ont des résultats équivalents. Certes MariaDB est encore en beta, mais je fais le pari que Monty program fera ce qu’il faut pour que la 1ère GA soit dispo pour la Percona MySQL User Conference du mois d’Avril.

MariaDB 5.3 à de bons résultats, cependant étant basée sur la branche 5.1 de MySQL, sa configuration est différente des autres versions. C’est la seule version de ce test avec 1 seul buffer_pool, ce qui est intéressant pour le temps d’exécution mais très pénalisant pour la scalabilité ie augmentation du nombre de requêtes concurrentes (cf résultats du bench TPS ci-après)

Mais le résultat le plus marquant est celui de la version 5.6 de MySQL qui explose la branche 5.5 avec 40% de temps en moins !!!

 

 

Nombre de transactions par seconde

  • Percona 5.5.12: 3401.152
  • MariaDB 5.3.5 *: 2912.667
  • MariaDB 5.5.20: 3185.623
  • MySQL 5.5.22: 3436.611
  • MySQL 5.6.4: 3601.915

 

dasini.net - transactions par seconde

Là, MariaDB 5.3 est en retrait, ce qui est normal du fait de son unique buffer pool.

MariaDB 5.5 est à la traîne par rapport à MySQL et Percona 5.5.

Le meilleur résultat est là encore MySQL 5.6 qui non seulement à les meilleurs temps de réponse (cf résultats du benche 95 centile au dessus) mais en plus à le meilleur débit des 5 candidats.

 

Je n’ai pas encore eu le temps de me pencher sur le pourquoi du comment, mais si cela ce confirme par la suite, je tire d’ores et déjà mon chapeau aux équipes MySQL d’Oracle pour leur excellent travail, d’autant plus que ces évolutions bénéficieront à MariaDB & Percona, dans un futur que j’espère très proche.

2ème partie de l’article …

Divers

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=40000000 \
--oltp-test-mode=complex --max-requests=0 --max-time=600 \
--num-threads=128 --oltp-read-only

innodb_buffer_pool_instances    4 (1 pour MariaDB 5.3)
innodb_buffer_pool_size    34359738368
innodb_doublewrite    ON
innodb_file_per_table    ON
innodb_flush_log_at_trx_commit    2
innodb_log_buffer_size    8388608
innodb_log_file_size    152043520
innodb_log_files_in_group    2
innodb_version  1.1.8-24.1 / 1.2.4 (ou XtraDB 1.1.6-20.1)

general_log    OFF
log_bin    OFF
slow_query_log    OFF

 

         
           Name: sbtest
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 30000237
 Avg_row_length: 224
    Data_length: 6741295104
Max_data_length: 0
   Index_length: 477085696
      Data_free: 6291456
 Auto_increment: 33800371
    Create_time: 2012-03-29 18:42:34
    Update_time: NULL
     Check_time: NULL
      Collation: utf8_swedish_ci
4

Attention au query cache

février 28, 2012

Selon le livre «Audit & optimisation, MySQL 5 – éditions Eyrolles», le cache de requêtes ou query cache est un système de cache mémoire interne à MySQL, transparent pour l’application, qui ne stocke que les requêtes SELECT et leurs résultats.

L’apport de ce cache est particulièrement dépendant de votre application. Il est coutume de dire qu’il est (très) pénalisant dans des environnements où les requêtes d’écritures sont nombreuses, notamment à cause de son mécanisme d’invalidation (et de problèmes de contentions de façon générale).

A l’opposé, il peut être intéressant de l’activer, dans des environnements à forte charges de lectures, si les mêmes requêtes reviennent très fréquemment, plus particulièrement lors de l’utilisation de tables MyISAM.

 

Cependant, un environnement à forte charge en lecture n’est pas une condition suffisante pour s’assurer de bonne performances avec le query cache, c’est ce que nous allons voir dans cet article.

 

Le contexte

L’idée principale de cet article, n’est pas de voir ce que MySQL « à dans le ventre », mais de connaître le coût du cache de requêtes, avec un hit ratio faible, dans une configuration «relativement proche» de ce que nous avons en production chez Viadeo.

J’ai utilisé sysbench pour générer 100 connexions simultanées, qui exécutent des SELECT sur une table InnoDB de 10 millions d’enregistrements :

sysbench –num-threads=100 –max-time=900 –max-requests=20000000 –test=oltp –oltp-table-size=20000000 –mysql-table-engine=innodb –oltp-test-mode=complex –oltp-read-only run

 

Les détails du bench sont dans le paragraphe divers, au bas de l’article.

 

Résumé

Avec un query cache hit très bas, même dans un contexte 100% SELECT, l’impact du cache de requêtes est désastreux sur les performances, que ce soit en TPS (graph 1) ou en 95ème centile (graph 2).

 

dasini.net - MySQL query cache

 

Les chiffres

— Query cache à 128 Mo

SHOW GLOBAL VARIABLES LIKE 'query_cache%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 134217728 |
| query_cache_strip_comments | OFF |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+

OLTP test statistics:
queries performed:
read: 2728040
write: 0
other: 389720
total: 3117760
transactions: 194860 (216.45 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 2728040 (3030.30 per sec.)
other operations: 389720 (432.90 per sec.)

Test execution summary:
total time: 900.2544s
total number of events: 194860
total time taken by event execution: 90014.3415
per-request statistics:
min: 40.23ms
avg: 461.94ms
max: 1276.36ms
approx. 95 percentile: 666.36ms

Threads fairness:
events (avg/stddev): 1948.6000/10.21
execution time (avg/stddev): 900.1434/0.08

Chiffres clés :

  • QC size : 128 Mo
  • TPS : 216,45
  • 95%tile : 666,36 ms

 

 

— Query cache à 256 Mo

SET GLOBAL query_cache_type=1; 
SET GLOBAL query_cache_size=268435456; 
SHOW GLOBAL VARIABLES LIKE 'query_cache%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 268435456 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+

OLTP test statistics:
queries performed:
read: 5601204
write: 0
other: 800172
total: 6401376
transactions: 400086 (444.47 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 5601204 (6222.60 per sec.)
other operations: 800172 (888.94 per sec.)

Test execution summary:
total time: 900.1385s
total number of events: 400086
total time taken by event execution: 90006.3589
per-request statistics:
min: 33.56ms
avg: 224.97ms
max: 601.63ms
approx. 95 percentile: 320.52ms

Threads fairness:
events (avg/stddev): 4000.8600/11.78
execution time (avg/stddev): 900.0636/0.04

Chiffres clés :

  • QC size : 256 Mo
  • TPS : 444,47
  • 95%tile : 320,52 ms

 

 

— Query cache à 64 Mo

SET GLOBAL query_cache_type=1; 
SET GLOBAL query_cache_size=67108864; 
SHOW GLOBAL VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 67108864 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+----------+
OLTP test statistics:
queries performed:
read: 7319270
write: 0
other: 1045610
total: 8364880
transactions: 522805 (580.84 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 7319270 (8131.73 per sec.)
other operations: 1045610 (1161.68 per sec.)
Test execution summary:
total time: 900.0881s
total number of events: 522805
total time taken by event execution: 90002.3195
per-request statistics:
min: 35.97ms
avg: 172.15ms
max: 380.79ms
approx. 95 percentile: 214.74ms
Threads fairness:
events (avg/stddev): 5228.0500/16.33
execution time (avg/stddev): 900.0232/0.02

Chiffres clés :

  • QC size : 64 Mo
  • TPS : 580,84
  • 95%tile : 214,74 ms

 

 

— Query cache OFF à 0 Mo

mysql> SET GLOBAL query_cache_type=0; 
SET GLOBAL query_cache_size=0; 
SHOW GLOBAL VARIABLES LIKE 'query_cache%';
+------------------------------+---------+
| Variable_name | Value |
+------------------------------+---------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 0 |
| query_cache_strip_comments | OFF |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
+------------------------------+---------+

OLTP test statistics:
queries performed:
read: 60504052
write: 0
other: 8643436
total: 69147488
transactions: 4321718 (4801.84 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 60504052 (67225.74 per sec.)
other operations: 8643436 (9603.68 per sec.)
Test execution summary:
total time: 900.0132s
total number of events: 4321718
total time taken by event execution: 89974.6206
per-request statistics:
min: 1.14ms
avg: 20.82ms
max: 466.96ms
approx. 95 percentile: 71.97ms
Threads fairness:
events (avg/stddev): 43217.1800/158.09
execution time (avg/stddev): 899.7462/0.01

 

Chiffres clés :

  • QC size : 0 Mo
  • TPS : 4801,84
  • 95%tile : 71,97 ms

 

 

Conclusion

 

Les requêtes créées par sysbench lors de ce test, génèrent un query cache hit ratio particulièrement faible < 10%

Ce dernier se calcul de la façon suivante : Qcache_hits / (Qcache_hits +Com_select)

 

Avec un QC hit ratio si bas, activer le QC à un impact désastreux sur les performances, même en lecture seule, est ce quelque soit sa taille (64 / 128 / 256 Mo ).

Lui mettre une taille beaucoup plus grande n’est pas une bonne idée (cf : « Audit & optimisation, MySQL 5 – éditions Eyrolles»).

 

Il est cependant possible de le paramétrer pour minimiser les pertes de performances (si il doit impérativement être activé). Dans le contexte de ce bench, la diminution du query_cache_min_res_unit, 512 au lieu de 4096 (car les résultat renvoyés sont très petit) associé à un query_cache_size de 256Mo à permit d’atteindre près de 2000 TPS (mieux que les 580 TPS obtenus avec 64Mo mais bien loin des 4800 TPS avec le QC désactivé).

 

A noter également qu’une diminution du nombre de connexions concurrentes n’inverse pas la tendance, même si l’écart diminue un peu (en d’autres termes plus il y a de connexions concurrentes, plus il y a de contentions (plutôt logique) !)

 

Une question que n’adresse pas ce test: A partir de quel pourcentage de hit ratio il est (serait) bénéfique d’activer le QC ?

J ‘essaierai d’y répondre dans un prochain article

 

Et vous, votre cache de requêtes vous veut il du bien ?

 

P.S. Les résultats sont (évidemment) les mêmes avec MariaDB 5.3.3 & Percona Server 5.5.19

 

 

Divers

Protocole

  • Start du serveur.
  • 2 run de 900 secondes
  • Je prend le meilleur des 2
  • Buffer pool suffisamment grand pour contenir toutes les données.

 

Serveur

  • Intel(R) Xeon(R) CPU X7542 @ 2.67GHz (x16)
  • RAM: 64 Go
  • OS: Ubuntu server

 

MySQL server version: 5.5.19 Percona Server with XtraDB (GPL), Release rel24.0, Revision 204

 

InnoDB configuration:

# InnoDB

  • innodb_file_per_table
  • innodb_buffer_pool_size = 8G
  • innodb_buffer_pool_instances = 2
  • innodb_log_file_size = 152428800
  • innodb_flush_log_at_trx_commit = 2
  • innodb_log_buffer_size = 8388608
  • innodb_support_xa = 1
  • innodb_thread_concurrency = 0
  • innodb_io_capacity = 200
  • innodb_doublewrite = 1
  • innodb_max_dirty_pages_pct = 75

 

Table information

CREATE TABLE `sbtest` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) COLLATE utf8_swedish_ci NOT NULL DEFAULT '',
`pad` char(60) COLLATE utf8_swedish_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci

 

Name: sbtest
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 10000060
Avg_row_length: 224
Data_length: 2247098368
Max_data_length: 0
Index_length: 137019392
Data_free: 4194304
Auto_increment: 10000001
Create_time: 2012-02-10 13:15:11
Update_time: NULL
Check_time: NULL
Collation: utf8_swedish_ci
Checksum: NULL

 

 

Type de requêtes:

  • SELECT c from sbtest where id=9992481
  • SELECT DISTINCT c from sbtest where id between 9997686 and 9997786 order by c
  • SELECT c from sbtest where id=10068344
  • SELECT SUM(K) from sbtest where id between 10073907 and 10074006
  • SELECT c from sbtest where id between 9330963 and 9331062

 

Calcul du query cache hit ratio:

Qcache_hits / (Qcache_hits +Com_select) < 1%

show global status like 'qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 21304 |
| Qcache_free_memory | 76320360 |
| Qcache_hits | 407451 |
| Qcache_inserts | 4745672 |
| Qcache_lowmem_prunes | 4691295 |
| Qcache_not_cached | 543 |
| Qcache_queries_in_cache | 54377 |
| Qcache_total_blocks | 130059 |
+-------------------------+----------+

 

mysql> show global status like 'com_sel%';
+---------------+---------+
| Variable_name | Value |
+---------------+---------+
| Com_select | 4746219 |
+---------------+---------+

 

select 407451/(407451+4746219);
+-------------------------+
| 407451/(407451+4746219) |
+-------------------------+
|                  0.0791 |
+-------------------------+

=> Taux de réussite du cache de requête est d'environ 8%

 

9

Retour sur le Meetup MariaDB SkySQL / LeMUG.fr

février 10, 2012

Voici le support de la conférence de Colin Charles (Monty Program Ab) du Meetup MariaDB SkySQL / LeMUG.fr du 1er février 2012 à Paris.

MariaDB: The new M in LAMP

enjoy 🙂

 

http://dimitrik.free.fr/blog/archives/2016/02/mysql-performance-scalability-on-oltp_rw-benchmark-with-mysql-57.html

Commentaires fermés sur Retour sur le Meetup MariaDB SkySQL / LeMUG.fr

Meetup MariaDB SkySQL / LeMUG.fr

janvier 17, 2012

SkySQL et Le MySQL User Group Francophone (lemug.fr) vous invitent à une rencontre MariaDB le 1 février 2012 à Paris, afin de découvrir ou approfondir vos connaissances de MariaDB, le SGBD 100% compatible avec MySQL développé par Michael « Monty » Widenius, le père fondateur de MySQL.

A cette occasion Colin Charles, MySQLer actuellement chez Monty Program Ab, animera une conférence intitulée: « MariaDB: The new M in LAMP »

 

 

Lieu

Patricks Irish Pub
33 rue de Montreuil
Paris 11ème
( à 5 mn de Bastille et Gare de Lyon à Ligne 8, Metro Faidherbe-Chaligny )
Visualiser le plan
Venez nombreux échanger avec la communauté MySQL
– Open Bar de 18h00 à 20h00 –
PAF : GRATUIT

Inscription (obligatoire)

 

Biographie :  Colin Charles
Colin Charles works at Monty Program Ab on MariaDB. He lives in Kuala Lumpur, Malaysia and had worked at MySQL since 2005. Before joining MySQL, he worked actively on the Fedora and OpenOffice.org projects. He’s spoken at many conferences – linux.conf.au, The MySQL Conference & Expo, foss.in, to name a few.

 

http://dimitrik.free.fr/blog/archives/2016/02/mysql-performance-scalability-on-oltp_rw-benchmark-with-mysql-57.html

1

Améliorations de l’optimiseur dans MariaDB

janvier 9, 2012

Les équipes de MariaDB ont énormément travaillées sur l’optimiseur de la version 5.3, notamment en permettant une réelle utilisation des sous-requêtes.

Voici un effet visuel de ces optimisations:

Avec MySQL 5.5, l’utilisation de tables dérivées (type de sous-requêtes dans la clause FROM d’un SELECT), donne le plan d’exécution suivant:

MySQL-5.5 > EXPLAIN SELECT * FROM (SELECT * FROM (SELECT * FROM City ccc ) cc ) c \G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra:
*************************** 2. row ***************************
id: 2
select_type: DERIVED
table: <derived3>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra:
*************************** 3. row ***************************
id: 3
select_type: DERIVED
table: ccc
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra:

 

Le même EXPLAIN avec MariaDB 5.3 donne:
MariaDB-5.3 >  EXPLAIN SELECT * FROM (SELECT * FROM (SELECT * FROM City ccc ) cc ) c \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: ccc
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra:

L’optimiseur comprend que les 2 niveaux de « SELECT * FROM » ne servent à rien, et réécrit donc la requête.

L’intérêt n’est heureusement pas que visuel:

Sur MySQL 5.5:

mysqlslap –create-schema=world -i10 -q »SELECT * FROM (SELECT * FROM (SELECT * FROM City ccc ) cc ) c ; » -S/tmp/mysql_55.sock
Benchmark
Average number of seconds to run all queries: 0.004 seconds

 

Sur MariaDB 5.3:
mysqlslap –create-schema=world -i10 -q »SELECT * FROM (SELECT * FROM (SELECT * FROM City ccc ) cc ) c ; » -S/tmp/mariadb_53.sock
Benchmark
Average number of seconds to run all queries: 0.002 seconds

Le test étant réalisé sur un petit volume de données, le temps écoulé n’est pas très important, cependant l’on peu noter que l’optimisation apporté par MariaDB, divise le temps d’exécution par 2 dans ce contexte (à conf équivalente, données équivalentes,…).

 

D’autres tests s’imposent, mais l’on peut déjà féliciter les équipes de MariaDB

 

http://dimitrik.free.fr/blog/archives/2016/02/mysql-performance-scalability-on-oltp_rw-benchmark-with-mysql-57.html

1

Meetup MySQL Viadeo / LeMUG.fr, les vidéos

décembre 12, 2011
Tags:

Les vidéos du meetup Viadeo/LeMUG sont dispo:

enjoy

1

Meetup MySQL Viadeo / LeMUG.fr, les photos

décembre 7, 2011
Tags:

Vous pouvez consulter les photos du meetup Viadeo/LeMUG sur le compte FB du MUG:

https://www.facebook.com/media/set/?set=a.10150393843136937.345851.46154571936&type=3

 

A venir les vidéos

enjoy

4

Retour sur le Meetup MySQL Viadeo / LeMUG.fr

novembre 18, 2011

Voici les supports des conférenciers du meetup Viadeo / LeMUG du 16 novembre:

 

 
English version

les photos et les vidéos des présentations sont disponibles.

 

enjoy 🙂

 

4