在CentOS 6.3 64bit上为Apache Traffic Server 4.2.3挂载SSD并压测

下面的安装假定是以root用户身份进行的，Linux服务器已经安装好系统，磁盘已经做好分区。
首先需要认识我们的Linux服务器的硬件配置和软件情况
硬件配置：
DELL R720 2U服务器
CPU  8核 Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
内存 32G
硬盘  系统盘 /dev/sda 300GB
      ssd /dev/sd{b,c} 240GB * 2
      普通磁盘 /dev/sd{d-l}  2TB * 9
软件配置：
操作系统 CentOS release 6.3 (Final)
内核     2.6.32-279.el6.x86_64

注意：我们这里仅是测试，只使用两块2TB普通SAS磁盘和一块240G SSD来供ATS测试，其他盘都没有使用。

下面给出今天测试的主角，三星240GB的PM853T服务器级SSD，这是2014年5月性能最强悍的产品

1.安装并配置好ATS 4.2.3
ATS挂载SSD需要磁盘和SSD都是裸盘，用户名和组名是tserver，具体参见前面的文档。

2.安装并配置好tsar监控软件
需要能够监控ATS，特别是ssdhit选项，参见博文
http://blog.csdn.net/tao_627/article/details/44808637


3.配置jtest双机压测环境
我目前采用两台主机搭建压测环境，一台就是配备裸盘SSD的ATS缓存代理服务器，一台就是jtest所在的服务器，部署示意图如下


假设ATS所在服务器ip是10.10.110.81，它的监听端口是8080，假设jtest所在服务器ip是10.10.110.149，假设压测域名是"ts.cn"(可以随便起)。
为了让jtest和Firefox正向代理都可以正常工作，我设置业务场景为正向+remap替换
配置records.config如下：
CONFIG proxy.config.reverse_proxy.enabled INT 1        #打开
CONFIG proxy.config.url_remap.remap_required INT 1     #1为只反向代理，0为正向+反向代理
CONFIG proxy.config.url_remap.pristine_host_hdr INT 0  #值改为0，这样可以释放对外域名的自由度。--这个修改视个人需要
CONFIG proxy.config.cache.ram_cache_cutoff INT 40      #值故意改小，是为了充分测试ssd，让数据不缓存RAM-cache
配置remap.config如下：
map http://ts.cn:9080/ http://10.10.110.149:9080
regex_map http://(.*) http://$1
然后运行下面的命令来更新配置文件
traffic_line -x

4.jtest压测ssd性能
按道理说，jtest作为ATS的附带工具，我们也应该在10.10.110.149上安装一个ATS，然后进入它的源码目录tools/jtest下面执行下面的命令
./jtest -P 10.10.110.81 -p 8080 -S ts.cn -s 9080 -z 1.0 -D 9080 -k 2 -c 500 -Z 1000 -q 100000000
其中：
con: 并发连接数。并发连接数，单进程单cpu处理能力取决于CPU与测试场景，请酌情设置，推荐小于9999
new: 每秒新建连接数。这个参数取决于并发连接数量与长连接效率。
ops: 每秒请求数。也作qps，是比较体现服务器性能的关键指标。
1byte：首字节平均响应时间。这个是体现整体转发效率的关键指标。
lat: 完成请求整体响应时间（收到最后一个字节）。cache系统性能关键指标。
bytes/per：每秒字节流量/每秒每连接流量
svrs：服务器端请求数
new：服务器端新建连接数
ops：服务器端每秒请求数
total：服务器端总请求的字节数
time：测试时间（秒）
err：出错数量（连接数）。稳定性测试中，这个数据可以作为一个关键指标。

对应的tsar数据

作为对比，如果

 CONFIG proxy.config.cache.ram_cache_cutoff INT 40960  //用于确定写入缓存的object大小，只有小于该数值的object才会缓存，默认为4M。

对应的tsar图如下

5.数据分析

从jtest的测试来看，每秒有500个client请求，ATS的QPS是7300/秒左右，带宽是130M；另外，从tsar cache数据显示来看，很明显，随着cutoff的不同，缓存命中从ram-cache很快转移到ssd中，服务器最初会有源站请求，很快就变为内存命中，此时主要是ssdhit，band为100.00表示带宽完全压满，ramhit和ssdhit的值之和，是100.00,这些数据说明，单个jtest已经完全压满网卡带宽，并且ssd充分利用，使得服务器QPS平均达到7300多。

最后的结论：

考虑到性能和成本的折衷，ssd的确能够在较低成本上解决大部分缓存的性能瓶颈问题，在不能增加物理内存的情况下，使得ATS性能有极大提升。

下面是jtest压测时，随着缓存命中急剧增加，ATS性能的变化曲线，很清楚地说明了这一点：

致谢：

感谢测试中遇到问题时朋友的帮忙，特别是耀扬，纸鸢，厦门-walker

未尽事宜：

上面使用一个jtest显然并未完全压榨ssd的性能，我们需要继续使用多个jtest实例来压测，这需要后续的补充。