设为首页 收藏本站
查看: 939|回复: 0

[经验分享] 在CentOS 6.3 64bit上为Apache Traffic Server 4.2.3挂载SSD并压测

[复制链接]

尚未签到

发表于 2015-11-14 09:18:08 | 显示全部楼层 |阅读模式
下面的安装假定是以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月性能最强悍的产品
DSC0000.jpg

DSC0001.jpg

DSC0002.jpg

  


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

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


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

假设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:出错数量(连接数)。稳定性测试中,这个数据可以作为一个关键指标。
DSC0004.jpg
对应的tsar数据
DSC0005.jpg
  作为对比,如果
   CONFIG proxy.config.cache.ram_cache_cutoff INT 40960  //用于确定写入缓存的object大小,只有小于该数值的object才会缓存,默认为4M。

  对应的tsar图如下
   DSC0006.jpg


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性能的变化曲线,很清楚地说明了这一点:
DSC0007.jpg


致谢:
  感谢测试中遇到问题时朋友的帮忙,特别是耀扬,纸鸢,厦门-walker
  未尽事宜:
  上面使用一个jtest显然并未完全压榨ssd的性能,我们需要继续使用多个jtest实例来压测,这需要后续的补充。
         版权声明:本文为博主原创文章,未经博主允许不得转载。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-139015-1-1.html 上篇帖子: Apache Shiro(安全框架) 下篇帖子: Linux下配置Apache+Mod_Wsgi+Django环境
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表