cluster性能测试

测试环境

服务器

192.168.1.1，192.168.1.2，192.168.1.3，192.168.1.4，192.168.1.5

CPU

1～3为Intel(R) Pentium(R) D CPU 2.80GHz， 4、5为Intel(R) Xeon(R) 3040 1.86GHz

操作系统

Centos 4.4

Cluster版本

5.1.27-ndb-6.3.17-cluster-gpl-log MySQL Cluster Server (GPL)

测试软件

sysbench

Cluster结构

192.168.1.1，192.168.1.2，192.168.1.3，192.168.1.4为data node，192.168.1.5为management node和sql node。192.168.1.4为第二台sql node，并运行sysbench。

Cluster中NoOfReplicas设为2，即每行数据储存两次，到两台data node上。

测试结果

测试是使用sysbench的oltp测试模式进行的，它的测试查询以事 务为单位，一个事务中包含了联机事务处理中常见的读和写操作。测试表的行数为100万，对1到128个线程并发做了测试。其中Innodb的测试数据作为 比较。innodb设置了足够大的buffer_pool，能够把整张表缓存到内存里。Cluster的测试中，除了内存选项，其他都是默认配置，在一个 测试中出现错误没有完成，是因为资源的限制导致错误，只是查询失败，集群并没有出现问题。

"2 data"的测试是使用2个data node的结果，NoOfReplicas同样是2，即两台数据节点中的内容完全相同。比较它和"4 data"的结果可以看出，虽然增加了节点，但由于增加了节点之间的通讯的消耗，查询的速度并没有提升反而下降。增加了节点的优势在于大并发量，当只有一 个sql node时，这个节点成为瓶颈，所以4个data node的优势没有表现出来。当使用两个sql node时，比较"2 data + 2 sql"和"4 data + 2 sql"就可看到使用更多的节点可以提高并发量。"4 data, disk"是使用硬盘的表格式测试，每个节点上表文件的大小为120M左右，用于缓存表内容的内存大小设置为64M，即表的内容不能完全缓存到内存中。这样在查询中需要硬盘的随机读写，使得查询的速度和并发量都有大幅下降。

	线程数	innodb	2 data + 1 sql	2 data + 2 sql	4 data + 1 sql	4 data + 2 sql	4 data, disk
每秒事务数	1	202.05	95.52	-	46.75	-	16.02
平均响应时间（秒）		0.0049	0.0105		0.0214		0.0624
每秒事务数	2	358.21	153.05	-	94.65	-	24.74
平均响应时间（秒）		0.0056	0.0131		0.0211		0.0808
每秒事务数	4	539.47	249.31	-	187.92	-	46.08
平均响应时间（秒）		0.0074	0.016		0.0213		0.0868
每秒事务数	8	616.36	340.24	-	295.99	-	83.07
平均响应时间（秒）		0.013	0.0235		0.027		0.0962
每秒事务数	16	574.6	427.09	-	404.7	-	94.71
平均响应时间（秒）		0.0278	0.0374		0.0395		0.1688
每秒事务数	32	538.16	431.75	413.09	421.8	491.55	97.42
平均响应时间（秒）		0.0594	0.0741	0.0774	0.0758	0.065	0.3281
每秒事务数	64	497.74	390.83	401.09	385.5	498.05	×
平均响应时间（秒）		0.1285	0.1637	0.1595	0.166	0.1294
每秒事务数	128	453.15	-	382.24	-	461.39	-
平均响应时间（秒）		0.2824		0.3348		0.2782

表中"-"代表没有进行测试，"×"代表测试中出现错误。