Partha Dutta posted pretty interesting post about iSCSI vs SCSI performance using SysBench.
This is nice to finally see some iSCSI benchmarks done with MySQL – something we were planning to do for a while but never ended up doing, mainly due to lack of hardware available for tests. It is also good to see Sysbench being used, as It is developed by our team, even more I write first version of this tool myself, for performance research (The new version was complete rewrite).
The problem I see in this test however – the benchmark is not fully described which makes it hard to judge what they really mean. Was it OLTP test or some other combination ? Was default table size used (that one is pretty small and would typically keep load CPU bound)
The image with results raises a lot of questions – why load is slower with 2 threads than with one threads in many cases ? Why difference is so small between these configuration even with large number of threads – we’re speaking about 16 SCSI disks on high end and single SATA on the low end.
The explanation could be for example it is log write bound rather than tablespace IO bound, which does not really benefit from multiple hard drives. SCSI drive getting slower than Serial ATA on large numer of connection could actually mean it is faster – regression with many threads often happens with Innodb if load becomes CPU bound rather than Disk bound.
I would also be especially careful making sure iSCSI driver peoperly does fsync() otherwise loosing database content might be the price for improved performance.
In general I’m pretty optimistic about iSCSI technology and think it will find more use with MySQL in years to come. One could use LVM with iSCSI and get some SAN like functionality.
I would not however view iSCSI as performance killer – if talking to your local SCSI drive is slower than talking to the same drive across the network – something is likely to be wrong, on other hands iSCSI allows to get much larger number of hard drives connected + easy roaming of hard drives between nodes while overhead should be limited.
Anyway that would be quite interestig to see more benchmarks.
