{"id":1196,"date":"2012-02-28T14:35:17","date_gmt":"2012-02-28T13:35:17","guid":{"rendered":"http:\/\/dasini.net\/blog\/?p=1196"},"modified":"2017-03-07T17:38:39","modified_gmt":"2017-03-07T16:38:39","slug":"attention-au-query-cache","status":"publish","type":"post","link":"https:\/\/dasini.net\/blog\/2012\/02\/28\/attention-au-query-cache\/","title":{"rendered":"Attention au query cache"},"content":{"rendered":"

Selon le livre \u00abAudit & optimisation, MySQL 5\u00a0– \u00e9ditions Eyrolles<\/a>\u00bb, le cache de requ\u00eates ou <\/a>query cache<\/em><\/a> est un syst\u00e8me de cache m\u00e9moire interne \u00e0 MySQL, transparent pour l’application, qui ne stocke que les requ\u00eates SELECT et leurs r\u00e9sultats.<\/p>\n

L’apport de ce cache est particuli\u00e8rement d\u00e9pendant de votre application. Il est coutume de dire qu’il est (tr\u00e8s) p\u00e9nalisant dans des environnements o\u00f9 les requ\u00eates d’\u00e9critures sont nombreuses, notamment \u00e0 cause de son m\u00e9canisme d’invalidation (et de probl\u00e8mes de contentions de fa\u00e7on g\u00e9n\u00e9rale).<\/p>\n

A l’oppos\u00e9, il peut \u00eatre int\u00e9ressant de l’activer, dans des environnements \u00e0 forte charges de lectures, si les m\u00eames requ\u00eates reviennent tr\u00e8s fr\u00e9quemment, plus particuli\u00e8rement lors de l’utilisation de tables MyISAM.<\/p>\n

 <\/p>\n

Cependant, un environnement \u00e0 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.<\/p>\n

 <\/p>\n

Le contexte<\/h2>\n

L’id\u00e9e principale de cet article, n’est pas de voir ce que MySQL \u00ab\u00a0\u00e0 dans le ventre\u00a0\u00bb, mais de conna\u00eetre le co\u00fbt du cache de requ\u00eates, avec un hit ratio faible, dans une configuration \u00abrelativement proche\u00bb de ce que nous avons en production chez Viadeo<\/a>.<\/p>\n

J’ai utilis\u00e9 sysbench<\/a> pour g\u00e9n\u00e9rer 100 connexions simultan\u00e9es, qui ex\u00e9cutent des SELECT sur une table InnoDB de 10 millions d’enregistrements\u00a0:<\/p>\n

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<\/em><\/p>\n

 <\/p>\n

Les d\u00e9tails du bench sont dans le paragraphe divers<\/em>, au bas de l’article.<\/p>\n

 <\/p>\n

R\u00e9sum\u00e9<\/h2>\n

Avec un query cache hit tr\u00e8s bas<\/strong>, m\u00eame dans un contexte 100% SELECT, l’impact du cache de requ\u00eates est d\u00e9sastreux sur les performances, que ce soit en TPS (graph 1) ou en 95\u00e8me centile<\/a> (graph 2).<\/p>\n

 <\/p>\n

\"dasini.net<\/a><\/div>\n

 <\/p>\n

Les chiffres<\/h2>\n

— Query cache \u00e0 128 Mo<\/h3>\n
SHOW GLOBAL VARIABLES LIKE 'query_cache%';\r\n+------------------------------+-----------+\r\n| Variable_name | Value |\r\n+------------------------------+-----------+\r\n| query_cache_limit | 2097152 |\r\n| query_cache_min_res_unit | 4096 |\r\n| query_cache_size | 134217728 |\r\n| query_cache_strip_comments | OFF |\r\n| query_cache_type | ON |\r\n| query_cache_wlock_invalidate | OFF |\r\n+------------------------------+-----------+\r\n\r\nOLTP test statistics:\r\nqueries performed:\r\nread: 2728040\r\nwrite: 0\r\nother: 389720\r\ntotal: 3117760\r\ntransactions: 194860 (216.45 per sec.)\r\ndeadlocks: 0 (0.00 per sec.)\r\nread\/write requests: 2728040 (3030.30 per sec.)\r\nother operations: 389720 (432.90 per sec.)\r\n\r\nTest execution summary:\r\ntotal time: 900.2544s\r\ntotal number of events: 194860\r\ntotal time taken by event execution: 90014.3415\r\nper-request statistics:\r\nmin: 40.23ms\r\navg: 461.94ms\r\nmax: 1276.36ms\r\napprox. 95 percentile: 666.36ms\r\n\r\nThreads fairness:\r\nevents (avg\/stddev): 1948.6000\/10.21\r\nexecution time (avg\/stddev): 900.1434\/0.08<\/pre>\n
Chiffres cl\u00e9s<\/strong><\/span>\u00a0:<\/strong><\/span><\/p>\n