公司最近要对上读写分离的中间件，打算对现下比较流行的中间件逐一进行性能测试。首先测试的是atlas.
此次测试分为两个部分，（1）atlas与直连db的性能比对，（2）event-threads参数对atlas性能的影响
一，简介
Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。
主要功能：
1.读写分离
2.从库负载均衡
3.IP过滤
4.自动分表
5.DBA可平滑上下线DB
6.自动摘除宕机的DB
Atlas相对于官方MySQL-Proxy的优势
1.将主流程中所有Lua代码用C重写，Lua仅用于管理接口
2.重写网络模型、线程模型
3.实现了真正意义上的连接池
4.优化了锁机制，性能提高数十倍
二：实验环境说明
| 服务 | IP | CPU | 内存 | 系统 |
| Atlas | 172.31.38.151 | 8 | 32G | CentOS 6.7 |
| master | 172.31.18.104 | 8 | 32G | CentOS 6.7 |
| Slave1 | 172.31.18.105 | 8 | 32G | CentOS 6.7 |
| Sysbench/salve2 | 172.31.38.150 | 8 | 32G | CentOS 6.7 |
三：atlas的安装与配置
1,在172.31.38.151这个服务器上部署atlas,下载atlas2.2.1
https://github.com/Qihoo360/Atlas/releases
2，安装
sudorpm -ivh Atlas-2.2.1.el5.x86_64.rpm
3，改配置文件
cd /usr/local/mysql-proxy/conf
cat test.cnf
[mysql-proxy]
admin-username = admin
admin-password = 123456
proxy-backend-addresses = 172.31.18.104:3306
proxy-read-only-backend-addresses = 172.31.18.105:3306@1, 172.31.38.150:3306@1
pwds = user1:/iZxz+0GRoA=
daemon = true
log-level =debug
log-path = /usr/local/mysql-proxy/log
sql-log = ON
keepalive = true
event-threads =16
log-level = message
instance = test
proxy-address = 0.0.0.0:1234
admin-address = 0.0.0.0:2345
charset = utf8
4，启动atlas
cd/usr/local/mysql-proxy/bin
# sudo ./mysql-proxyd test start
OK: MySQL-Proxy of test is started
查看服务进程是否在：
ps -ef | grep mysql-proxy
root 6874 1 0 01:16 ? 00:00:00/usr/local/mysql-proxy/bin/mysql-proxy--defaults-file=/usr/local/mysql-proxy/conf/test.cnf
root 6875 6874 0 01:16 ? 00:00:00/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/usr/local/mysql-proxy/conf/test.cnf
root 6886 2714 0 01:16 pts/0 00:00:00 grep mysql-proxy
5，进入管理界面：
在主从服务器分别给atlas授权管理用户：
grant all privileges on *.* to admin@172.31.38.150 identified by '123456';
mysql -h127.0.0.1 -P2345 -uadmin -p123456
四：atlas与直连db的性能比对测试
此次测试设置了三组对照组：
1，atlas转发sql到mater
2, atlas转发sql到一主两从的mysql集群
3，直连db
测试工具为sysbench,使用oltp的测试脚本。
执行下面的命令测试sysbench连接Atlas:
./bin/sysbench --test=/usr/sysbench/tests/db/oltp.lua \
--oltp-skip-trx=on \
--num-threads=1 \
--max-requests=80000 \
--oltp-test-mode=nontrx \
--db-driver=mysql \
--mysql-db=sbtest \
--mysql-host=172.31.38.151 \
--mysql-port=1234 \
--mysql-user=user1 \
--mysql-password=123456 \
--oltp-nontrx-mode=select \
--db-ps-mode=disable \
--mysql-ignore-errors=1062 prepare ( run cleanup )
上述命令是sysbench执行80000次随机select操作，这80000次操作都是非事务的。 通过修改 --oltp-nontrx-mode 选项，可以执行update和insert操作。 通过修改 --num-threads 参数，可以调整并发测试线程的个数。
执行下面的命令测试直连DB：
./bin/sysbench --test=/usr/sysbench/tests/db/oltp.lua \
--oltp-skip-trx=on \
--num-threads=1 \
--max-requests=80000 \
--oltp-test-mode=nontrx \
--db-driver=mysql \
--mysql-db=sbtest \
--mysql-host=172.31.18.104\
--mysql-port=3306 \
--mysql-user=user1 \
--mysql-password=123456 \
--oltp-nontrx-mode=select \
--db-ps-mode=disable \
--mysql-ignore-errors=1062 prepare ( run cleanup )
利用sysbench测试了并发线程个数不同的情况下，分别执行80000次 select，update 和 insert 三种操作。每组测试重复三次取平均值。
以下是三个场景下的qps对比：
以上数据对应的折线图如下：
同时测试了sysbench不同并发线程下，完成每个SQL操作平均时间（单位：ms，时间越短，系统性能越好）。具体数据对比如下所示：
以上数据对应的折线图如下：
由以上统计结果可知：
（1）在只能主库的情况下，通过atlas转发sql要比直连db性能下降了大约40%-50%
（2）通过atlas引入从库的负载均衡后，并发小的时候atlas并无优势，但是随着并发量的增大，atlas优势明显.
（3）从每条sql的平均响应时间来看，引入从库的负载均衡后，在并发小时atlas的响应时间大概是直连db的1-1.5倍，但是当高并发时，atlas的响应时间明显比直连db的时候少。
由以上测试结果可知atlas适用于一主多从的高并发场景。
五：event-threads参数对atlas性能的影响
event-threads 是 Atlas 工作时创建的工作线程个数，这个值设置的不同对 Atlas 性能也有比较明显的影响。 将event-threads 分别设置为1，4，8，16，24，32，40，48进行测试，Atlas转发select请求时的 QPS 和完成每条SQL操作时间对比。具体对比结果如下所述：
qps数据：
以上数据对应的拆线图为：
平均响应时间：
以上数据对应的拆线图为：
测试的结果可知，并发量小的时候event-threads参数的影响不大，但是随着并发的增大，event-threads参数设置1，4时,atlas的qps明显低于event-threads设置成>=8的时候，同时平均响应时间也明显增长。但是当events-threads设置成与cpu核数相等和cpu的2-6倍时，qps和sql的平均响应时间都差别不大。由此可见，event-threads不能设置成小于cpu的核心数。
参考：https://github.com/Qihoo360/Atlas/wiki/Atlas%E7%9A%84%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95