Tuesday, November 25, 2008

950k reads per second on 1 datanode

i spent last night adding 75% of the next step for our multi-threaded datanode.
and got new numbers...
the config is the same as earlier post, with the exception that
MaxNoOfExecutionThreads=8

flexAsynch -ndbrecord -temp -con 4 -t 16 -p 312 -a 2 -l 3 -r 2
insert average: 461584/s min: 451928/s max: 474254/s stddev: 2%
update average: 533083/s min: 530950/s max: 537351/s stddev: 0%
delete average: 564388/s min: 559265/s max: 567143/s stddev: 0%
read average: 948954/s min: 937288/s max: 959262/s stddev: 0%

also tried using SCI instead of gigabit ethernet
flexAsynch -ndbrecord -temp -con 4 -t 16 -p 256 -a 2 -l 3 -r 2
insert average: 568012/s min: 550389/s max: 578367/s stddev: 2%
update average: 599828/s min: 598480/s max: 602175/s stddev: 0%
delete average: 614036/s min: 612440/s max: 616496/s stddev: 0%
read average: 1012472/s min: 1003429/s max: 1024000/s stddev: 0%

i.e with SCI the 1M reads/sec limit is reached! (on 1 datanode)
i think this should also be achievable on ethernet by adding some
more optimizations (let api-application start transactions directly
on correct TC-thread)

---

comments:
1) the new "feature" is multi threading the transaction coordinator
aka MT-TC

2) this part will likely not make the mysql cluster 6.4.0-release

3) our multi-threading architecture seems promising,
in less than a month i managed to double the throughput
(in a admittedly unrealistic benchmark, but still)

4) the 25% missing from the current patch is node-failure handling
and a "rcu-like" lock which will be used for reading/updating distribution
(it's read for each operation, and updated during node-failure,node-recovery and
online table repartitioning)

8 comments:

Matthew Montgomery said...

Jonas does ndbmtd show a negative performance impact when you set MaxNoOfExecutionThreads to greater than 8 ?

Jonas Oreland said...

8 is greatest accepted value.
it refuses to start is set higher.
so yes, definitely lower performance

漢(と書いてオトコ) said...

How good is it compared to single threaded ndbd? I guess the result of prior benchmark(500k reads/s) is even better than ndbd. I wonder how good the latest ndbmtd is compared to ndbd.

Cyril Scetbon said...

Really good news. Is there any dead line for the 6.4 release ?

Great work Jonas

Jonas Oreland said...

i think (current) plan is to make a beta-release early next year

Cyril Scetbon said...

Great news ! Did you make the same test with 6.3.x version ? Do we get the same performance with a 6.3.x and a 6.4.x if multithreading is disabled ?

Happy New Year and we hope that we'll see a lot of interesting new posts this year !

World of Warcraft Gold Guides said...

good post :)

zampettim said...

Is it possible to get the code to the flexAsync benchmark client. I'm trying to get a cluster up and running, and I need very high write rates. It sounds like seeing the flexAsync code may help with building my own NDB API client.