生活宝|商城|团购|房产|招聘|外卖|交友|微博|汽车|同城|游戏|贷款|发稿|建站|软件|客服
上海论坛

阿里七层流量入口 Tengine硬件加速探索之路

更新于 2018-6-4 17:08:55 140人阅读 0人回复 显示全部楼层 倒序浏览

a
0 0
  @ME:   
  • TA的每日心情
    奋斗
    2018-7-2 15:35
  • 签到天数: 96 天

    连续签到: 1 天

    [LV.6]常住居民II

    发表于 2018-6-4 17:08:55 | 显示全部楼层 |阅读模式
    53快服 销量提升50%

    马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

    您需要 登录 才可以下载或查看,没有帐号?快速注册

    x
    摘要: Tengine在软件层面已经有了深度的调试和优化经验,但是在硬件层面,通用处理器(CPU)已经进入了摩尔定律,有了瓶颈。而在业务量突飞猛进的当下,如何利用硬件来提升性能,承载双11等大型活动的洪峰流量,保障活动平稳度过呢?本文作者:王发康,花名毅松,负责集团主站统一接入层Tengine的开发与维护。
    Tengine在软件层面已经有了深度的调试和优化经验,但是在硬件层面,通用处理器(CPU)已经进入了摩尔定律,有了瓶颈。而在业务量突飞猛进的当下,如何利用硬件来提升性能,承载双11等大型活动的洪峰流量,保障活动平稳度过呢?
    本文作者:王发康,花名毅松,负责集团主站统一接入层Tengine的开发与维护。今天分享的主题是《阿里七层流量入口Tengine硬件加速探索之路》。
    接入层系统介绍
    接入层是2015年阿里巴巴全站HTTPS诞生的一个产品。作为一个电商网站,为了保护用户信息安全、账户、交易的安全,全站HTTPS是势在必行,如果淘宝、天猫、聚划算等各业务方在后端各自做接入层,机器成本高,而且证书管理复杂。为了解决问题,我们做了统一接入层,来做HTTPS卸载和流量分发等通用功能。
    所有的阿里集团流量通过四层LVS,到达统一接入层,统一接入层根据不同的维度域名转发到对应的后端APP,并且提供智能的流量分发策略。因为抽象出一层,通用的安全防攻击、链路追踪等高级功能,都可以在这一层统一实现。
    接入层是集团所有流量的入口,它的稳定性是非常重要的。同时,接入层提供了这么多高级功能,所以对其性能的挑战也非常大。业务驱动了技术创新,2017年接入层在硬件加速领域迈出了第一步。
    性能瓶颈分析及解决
    我们要对自己的系统做性能优化,首先我们要找到系统的瓶颈点,并且进行分析与调研。
    主站接入层承载集团90%以上的入口流量,同时支持着很多高级功能,比如HTTPS卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等,这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多,所以这就导致Tengine的CPU消耗比较分散,消耗CPU比较大的来自两个处HTTPS和Gzip,这就是性能瓶颈之所在。
    一、HTTPS卸载篇
    虽然全站HTTPS已经是一个老生常谈的话题,但是国内为何能做到的网站却还是屈指可数?原因简单总结来说有两点,首先使用HTTPS后使得网站访问速度变“慢”,其次导致服务器CPU消耗变高、从而机器成本变“贵”。
    软件优化方案:如Session复用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS等。 但软件层面如何优化也无法满足流量日益增长的速度,加上CPU摩尔定律已入暮年,使得专用硬件卸载CPU密集型运算成为业界一个通用解决方案。
    Tengine基于Intel QAT的异步加速方案总体架构
    由三部分组成Tengine的ssl_async指令、OpenSSL + QAT Engine及QAT Driver。其中Tengine通过适配OpenSSL-1.1.0的异步接口,将私钥操作卸载至Intel提供的引擎(QAT engine)中,引擎通过 QAT驱动调用硬件完成非对称算法取回结果。
    该方案在Tengine2.2.2中已经开源。
    Tengine启用ssl_async QAT加速后的效果如何?
    RSA套件提升3.8倍(8核时)
    ECDHE-RSA提升2.65倍(8核时)
    ECDHE-ECDSA(P-384) 提升2倍(16核时)
    ECDHE-ECDSA(P-256) 8核达到QAT硬件处理峰值16k左右, 只有23%的性能提升。
    HTTPS卸载方案可以减少物理机数量,节省CPU资源,为公司带来价值。
    二、Gzip卸载篇
    当前接入层Gzip模块的CPU占比达到15-20%,如果我们能卸载掉Gzip的CPU消耗,让出来的CPU就可以用于处理更多请求和提升性能。
    然而目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白,阿里在接入层结合硬件加速技术卸载Gzip调研了几套方案:
    方案一是和Intel合作的QAT卡的加速方案,直接把相关软件算法固化到硬件中去,链路会更精简。
    方案二智能网卡方案,需要把Tengine一部分业务逻辑抽取到网卡中做,其成本及风险高,而且只是对zlib进行软件卸载,相对于QAT并不具有加速作用。
    方案三是FPGA卡方案,相对来说开发成本较高,且相关资源匮乏。
    综上评估,选择方案一对Gzip进行卸载及加速。
    Tengine Gzip 硬件加速方案实践
    左边的图是软件方案,请求进来后,在软件层面做一些压缩,全部是用CPU在做。右边是通过QAT卡来加速,把红色那部分全部卸载到QAT卡里,通过改造Tengine中的Gzip这个模块,让它去调用QAT的驱动,通过硬件做压缩,最终送回Tengine传输给用户。
    在这个过程中,我们也遇到了非常多的坑。
    使用的第一版驱动Intel-Qat 2.6.0-60,当QPS为1k左右时,从上图可以看出,横坐标是时间,纵坐标是CPU消耗百分比,跑到第五秒左右,CPU很快打满,这相当于根本跑不起来。
    针对这个问题,我们使用strace进行相关系统热点函数统计发现,其CPU主要消耗在ioctl系统函数上,如下所示:
    ioctl主要是做上层应用程序和底层通讯的,并且CPU消耗中90%以上都是消耗在内核态。因为最初的每个压缩请求都要送到硬件中去,buffer需要开辟连续的物理内存,系统跑久了,一旦遇到连续内存分配不成功的情况,就会需要ioctl去分配内存,出现频繁调用 compact_zone进行内碎片整理,其调用热的高达88.096%,如果分配失败了,就会触发内存去做碎片整理,所以就会出现sys态CPU持续上升的情况。
    这个问题解决后,也并没有那么顺利,我们遇到了下面的问题。
    在日常压测时,我们发现CPU用了Gzip卸载方案后,节省效果上并没有明显的提升。user态CPU降低了10%左右,但是sys态CPU相对于软件版的CPU提升了10%。所以,节省效果不明显。
    经分析,我们发现使用QAT后,部分系统函数CPU占比变高,如下图所示(注:左边的是使用QAT后各系统热点函数,右边是软件版原生tengine的各系统热点函数)open、ioctl、futex执行 时间占比高达8.95(注:3.91 + 2.68 + 2.36),而未使用版本对应占比时间才0.44(注:0.24 + 0.14 + 0.06)。

    您需要登录后才可以回帖 登录 | 快速注册

    本版积分规则

    品牌广播台 更多>>
    便民工具
    返回顶部快速回复返回列表联系客服手机访问
    关于我们 | 联系我们 | 广告服务 | 网站导航 | 诚聘英才 | 友情链接 | 免责申明 |  帮助中心 | 手机访问 | 排行榜 | 小黑屋 | 设首页 | 加收藏
    © 2011-2017 上海论坛 版权所有 沪ICP备11017971号-7    在线客服 举报 郑重声明:本站只提供网上自由交流讨论,所有个人言论并不代表本站立场
    快速回复 返回顶部 返回列表