Atlas的性能测试
服务器操作系统：Centos 6.2
CPU：Intel(R) Xeon(R) E5620 @ 2.40GHz *4
内存：8GB
硬盘：350GB
Atlas版本：2.0.3
Mysql版本：5.5.33
测试工具
Sysbench（版本：0.4.12）
1.测试通过Atlas转发SQL请求与直连DB发送SQL请求这两种情形下的性能差距。
2.测试配置文件中event-thread参数对Atlas的影响，并找出最优值。
利用上述配置的4台服务器搭建了一个Atlas性能测试环境。服务器A运行着主库，服务器B运行着从库，服务器C运行Atlas系统，服务器D运行
sysbench。四台服务器处在同一个网段中。具体的拓扑图如下所示：
有关Atlas系统安装与配置，请参考文档《Atlas的安装》，sysbench直接通过yum安装（yum install sysbench）。
首先，我们利用sysbench通过Atlas转发SQL请求和直接连接DB发送SQL请求时，测试这两种情况下的QPS和每条SQL请求平均处理时间。我们通过sysbench测试发送三类SQL请求：select，update，insert。每类请求都是单独发送。具体的操作过程如下所示：
执行下面的命令测试sysbench连接Atlas
sysbench --test=oltp --num-threads=1 --max-requests=80000--oltp-test-mode= nontrx --db-driver=mysql --mysql-db=my_db --mysql-host=192.168.0.12 --mysql-port=1234 --mysql-user=buck --mysql-password=buck --oltp-nontrx-mode=select --db-ps-mode=disable prepare (run,cleanup)
上述命令是sysbench执行80000次随机select操作，这80000此操作都是非事务的。通过修改--oltp-nontrx-mode选项，可以执行update和insert操作。通过修改--num-threads参数，可以调整并发测试线程的个数。sysbench创建表的语句是：
CREATE TABLE sbtest (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
k int(10) unsigned NOT NULL DEFAULT '0',
c char(120) NOT NULL DEFAULT '',
pad char(60) NOT NULL DEFAULT '',
PRIMARY KEY (id),
KEY k (k)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1
执行下面的命令测试sysbench直连DB：
sysbench --test=oltp --num-threads=1 --max-requests=80000 --oltp-test-mode= nontrx --db-driver=mysql --mysql-db=my_db --mysql-host=192.168.0.13 --mysql-port=3306 --mysql-user=buck --mysql-password=buck --oltp-nontrx-mode=select --db-ps-mode=disable prepare (run,cleanup)
利用sysbench测试了并发线程个数不同的情况下，分别执行80000次select，update和insert三种操作。测试连接Atlas和直连DB这两种情况下的QPS（QPS越大，系统性能越好），每组数据重复测试三次后去平均值，具体数据对比如下表所示：
上表对应的折线图如下所示：
从表一可以看出，当sysbench的并发测试线程较少时，连接Atlas和直连DB的QPS差距较大。这主要是因为当sysbench并发线程少时，Atlas的性能没有得到充分的发挥，sysbench只有很少的线程向Atlas发送请求，此时网络延迟对QPS的影响是最主要的。当sysbench的并发测试线程较大时，此时Atlas的性能就得到了充分的发挥，此时QPS的对比是连接Atlas与直连DB性能对比的真实的反应，网络延迟对QPS的影响作用就显得很小了。从表一数据来看，通过Atlas发送select请求时的QPS是直连DB时60%左右，而update和insert请求对应的QPS则更高一些，相当于直连DB时的80%左右。由此看来利用Atlas转发SQL请求带来的性能下降虽有下降，但完全可以接受。
从表二可以看出，在sysbench的并发测试线程较少的情况下，连接Atlas和直连DB时完成每条SQL操作的时间差距较大，造成这种结果的原因也是由于Atlas性能未充分发挥，网络延迟起了主要作用。当sysbench并发测试线程较高时，Atlas的性能充分发挥，此时完成每条SQL操作的时间差距对比，才是Atlas的真正性能反应。通过Atlas发送SQL请求时的每条操作完成时间大约是直连DB时1.5倍，由此看来利用Atlas转发SQL请求带来的时间延迟不是非常明显，同样也是完全可以接受。
event-threads是Atlas工作时创建的工作线程个数，这个值设置的不同对Atlas性能也有比较明显的影响。我们分别测试将event-threads设置为4，8，16时，Atlas转发select，update和insert三类操作请求时的QPS和完成每条SQL操作时间对比。具体对比结果如下所述：
1.利用sysbench分别并发16，32，64和128个测试线程，执行80000次select操作，Atlas具体的QPS对比如下表所示：
上表对应的折线图如下所示：
完成每条select操作时间（单位：ms）对比如下表所示：
上表对应的折线图如下所示：
2.利用sysbench分别并发16，32，64和128个测试线程，执行80000次update操作，Atlas具体的QPS对比如下表所示：
上表对应的折线图如下所示：
完成每条update操作时间（单位：ms）对比如下表所示：
上表对应的折线图如下所示：
3.利用sysbench分别并发16，32，64和128个测试线程，执行80000次insert操作，Atlas具体的QPS对比如下表所示：
上表对应的折线图如下所示：
完成每条insert操作时间（单位：ms）对比如下表所示：
上表对应的折线图如下所示：
从Atlas处理三类SQL操作的QPS和完成每条SQL操作的时间对比来看，将event-threads参数设置为CPU个数的2-4倍较为合理。将event-threads参数设置为CPU个数的两倍时，带来的QPS提升较为明显，将其设置为CPU个数的四倍时，QPS也有提升但不是非常明显。对于处理每条SQL操作的时间，通过提高event-threads值是没有显著效果的。
所以我们建议使用者：如果追求Atlas处理SQL请求时的QPS，将event-threads值设置为CPU个数的2-4倍。如果追求Atlas处理SQL请求的完成时间，将event-threads值设置为CPU个数即可。
本文主要测试了通过Atlas转发SQL请求与直连DB发送SQL请求这两种情形下的性能差距，和event-threads值对Atlas的性能影响。从测试结果来看，Atlas性能表现较为优秀，并没有明显的性能下降。同时在测试中发现Atlas系统属于CPU密集型任务，相对于磁盘IO和内存占用率而言，Atlas对CPU消耗显得最为明显，所以建议在部署Atlas的时候需要优先考虑服务器的CPU性能。