14 seconds query time to read from tl_iso_requestcache

[leofeyer]

If the tl_iso_requestcache table grows, the queries become really slow and the MySQL load increases. There are hundreds of these entries in the mysql-slow.log:

# User@Host: foo[foo] @ localhost []
# Thread_id: 1048590  Schema: bar  QC_hit: No
# Query_time: 14.883989  Lock_time: 0.000094  Rows_sent: 0  Rows_examined: 1900188
# Rows_affected: 0  Bytes_sent: 387
SET timestamp=1712010692;
SELECT * FROM tl_iso_requestcache WHERE store_id='4' AND config='a:3:{s:7:\"filters\";a:1:{i:428;a:1:{i:0;O:35:\"Isotope\\RequestCache\\CategoryFilter\":1:{s:12:\"\0*\0arrConfig\";a:3:{s:9:\"attribute\";s:9:\"c.page_id\";s:8:\"operator\";s:2:\"in\";s:5:\"value\";a:40:{i:0;i:653;i:1;i:518;i:2;i:517;i:3;i:664;i:4;i:728;i:5;i:754;i:6;i:761;i:7;i:607;i:8;i:609;i:9;i:611;i:10;i:735;i:11;i:687;i:12;i:733;i:13;i:590;i:14;i:686;i:15;i:668;i:16;i:822;i:17;i:591;i:18;i:592;i:19;i:750;i:20;i:752;i:21;i:753;i:22;i:488;i:23;i:489;i:24;i:513;i:25;i:525;i:26;i:474;i:27;i:475;i:28;i:594;i:29;i:782;i:30;i:537;i:31;i:683;i:32;i:595;i:33;i:671;i:34;i:672;i:35;i:468;i:36;i:714;i:37;i:793;i:38;i:472;i:39;i:469;}}}}}s:8:\"sortings\";N;s:6:\"limits\";N;}' LIMIT 0,1;
# Time: 240402  0:31:33
# User@Host: foo[foo] @ localhost []
# Thread_id: 1048595  Schema: bar  QC_hit: No
# Query_time: 14.817785  Lock_time: 0.000086  Rows_sent: 0  Rows_examined: 1900192
# Rows_affected: 0  Bytes_sent: 387
SET timestamp=1712010693;
SELECT * FROM tl_iso_requestcache WHERE store_id='4' AND config='a:3:{s:7:\"filters\";a:1:{i:428;a:1:{i:0;O:35:\"Isotope\\RequestCache\\CategoryFilter\":1:{s:12:\"\0*\0arrConfig\";a:3:{s:9:\"attribute\";s:9:\"c.page_id\";s:8:\"operator\";s:2:\"in\";s:5:\"value\";a:39:{i:0;i:653;i:1;i:518;i:2;i:517;i:3;i:664;i:4;i:728;i:5;i:754;i:6;i:761;i:7;i:607;i:8;i:609;i:9;i:611;i:10;i:735;i:11;i:687;i:12;i:733;i:13;i:590;i:14;i:686;i:15;i:668;i:16;i:822;i:17;i:591;i:18;i:592;i:19;i:750;i:20;i:752;i:21;i:753;i:22;i:488;i:23;i:489;i:24;i:513;i:25;i:525;i:26;i:474;i:27;i:475;i:28;i:594;i:29;i:782;i:30;i:537;i:31;i:683;i:32;i:595;i:33;i:671;i:34;i:672;i:35;i:468;i:36;i:713;i:37;i:472;i:38;i:714;}}}}}s:8:\"sortings\";N;s:6:\"limits\";N;}' LIMIT 0,1;
# User@Host: foo[foo] @ localhost []
# Thread_id: 1048597  Schema: bar  QC_hit: No
# Query_time: 12.685276  Lock_time: 0.000106  Rows_sent: 1  Rows_examined: 1900177
# Rows_affected: 0  Bytes_sent: 1034
SET timestamp=1712010693;
SELECT * FROM tl_iso_requestcache WHERE store_id='4' AND config='a:3:{s:7:\"filters\";a:1:{i:428;a:1:{i:0;O:35:\"Isotope\\RequestCache\\CategoryFilter\":1:{s:12:\"\0*\0arrConfig\";a:3:{s:9:\"attribute\";s:9:\"c.page_id\";s:8:\"operator\";s:2:\"in\";s:5:\"value\";a:37:{i:0;i:653;i:1;i:518;i:2;i:517;i:3;i:664;i:4;i:728;i:5;i:754;i:6;i:761;i:7;i:607;i:8;i:609;i:9;i:611;i:10;i:735;i:11;i:687;i:12;i:733;i:13;i:590;i:14;i:686;i:15;i:668;i:16;i:822;i:17;i:591;i:18;i:592;i:19;i:750;i:20;i:752;i:21;i:753;i:22;i:488;i:23;i:489;i:24;i:513;i:25;i:525;i:26;i:474;i:27;i:475;i:28;i:594;i:29;i:782;i:30;i:537;i:31;i:683;i:32;i:595;i:33;i:671;i:34;i:672;i:35;i:468;i:36;i:713;}}}}}s:8:\"sortings\";N;s:6:\"limits\";N;}' LIMIT 0,1;

We have two clients who are affected by this and the only remedy currently is to truncate the table every hour.

[aschempp]

any idea why it is slow? Are we missing a useful index or thelike?

[fritzmg]

My guess would be that the AND config='…' makes it slow. May be a

'store_id,config'   => 'index'

index can fix it?

[aschempp]

@leofeyer can you test that on these systems?

[fritzmg]

i.e.

// contao/dca/tl_iso_requestcache.php
$GLOBALS['TL_DCA']['tl_iso_requestcache']['config']['sql']['keys']['store_id,config'] = 'index';

[aschempp]

I don't think that can really work though, because config is a BLOB field?

[fritzmg]

Yeah, I guess not. I think the request cache implementation needs to be overhauled then.

[fritzmg]

Storing the shop config as a simple md5 hash in a fixed length field might be an easy fix?