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

爱被打了一巴掌 2022-08-05 12:24 162阅读 0赞

下面的安装假定是以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月性能最强悍的产品

![Center][]

![Center 1][]

![Center 2][]

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所在的服务器，部署示意图如下  
![Center 3][]  
  
假设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：出错数量（连接数）。稳定性测试中，这个数据可以作为一个关键指标。  
![Center 4][]  
对应的tsar数据

![Center 5][]

作为对比，如果

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

对应的tsar图如下

![Center 6][]

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性能的变化曲线，很清楚地说明了这一点：

![Center 7][]

致谢：

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

未尽事宜：

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

[Center]: /images/20220805/fd4d524d211143268acac57ff5349165.png
[Center 1]: /images/20220805/bee2f178d8ed4ea49845e8bf7a07ba7d.png
[Center 2]: /images/20220805/75ada81dbff34c97ac0a7fb3dccfbda7.png
[Center 3]: /images/20220805/2783ccc2b556422d817a92f8afe5e8ed.png
[Center 4]: /images/20220805/12697042568c499ea362f006508ec0b2.png
[Center 5]: /images/20220805/78fd105f60b64f72a070b3e489ac1522.png
[Center 6]: /images/20220805/3de36f9b08d040b8a654323a5414bd8a.png
[Center 7]: /images/20220805/11c39e5722e44a2ba5aa53c2f60aa5b4.png