Very nice work!

The fact that compression to 4K shows nearly 7% compression failures during load is indicative that this table is not a good candidate for compression to 4K. I also tried that and got same results (i.e.: nearly 7% compression failures for 4K and 0.1% failures for 8K). That is why we say in the documentation that if the compression failures are greater then 1% then it is not a good idea to compress such tables.
Performance is so sensitive to compression failures because not only the failures entail split and recompression (which is heavy duty operation) but also if we are hitting failures then we are unlikely to have much space in the page for modification log. Remember that InnoDB, attempts to avoid multiple calls to recompression by keeping a log of changes made to a page in a per page modification log. This micro journal resides in the free space within a page. If a page is compressed to a size where 16K data just barely fits into the page size then not much is left for this log and hence extra calls to recompression.

BTW: if you try to capture innodb_cmp during read/write run of sysbench you’ll see roughly 2% failures for 8K pages and nearly 60% failures for 4K.

regards,
inaam

Thanks for the feedback. sysbench, I already tweaked to suite the needs, even though I couldn’t contribute the code back as nobody looks like taking any patches out there.

Anyway,

Batches mean, single inserts here. And mysqldump by default uses –opt and I did not use –no-opt for sure. I was also bit surprised on 4K/2K; but after multiple iterations, the results appear in the same way.. I may file a bug on my findings as well.. Just watch my second post today or tomorrow and let me know if you have any questions on top.

Also load time looks rather strange – what exactly did you do ? did you do dump with –no-opt so mysqldump would use single value inserts ? Or do you mean something else by “not batches” ?

Though I should say compression is where using sbtest is pretty bad choice – it is designed to deal with data sizes but it does not really uses strings which would have compression properties any close to real world.

This is one of the challenge of testing system with uses compression – you do not only need to repeat the cardinalities and lengths of rows matching scenario you’re interested in but also compression properties.