更多深度文章，请关注云计算频道：https://yq.aliyun.com/cloud

10+倍性能提升全过程--优酷账号绑定淘宝账号的TPS从500到5400的优化历程

背景描述

2016年双11在淘宝上buy buy买的时候，天猫和优酷土豆联合促销。天猫双11购物当天，他们给优酷会员超XXX元。这个过程需要用户在优酷这边绑定淘宝账号(登录优酷，提供淘宝账号，优酷调用淘宝API绑定两个账号)并给予会员并使其权益生效(观看付费电影、免费广告等。).

这里涉及到优酷的两个部门：护照(在上海负责登陆和绑定账号，下面优化流程主要是护照部分)；会员(在北京，负责赠送会员，保证权益的有效性)

双11活动之前，Passport的绑定账号功能一直在运行，但是并没有遇到大促带来的挑战。

构件的结构转换

接入中间件DRDS，让优酷的数据库可以支持拆分和分解MySQL的压力。

访问中间件vipserver以支持负载平衡。

访问集团DRC以确保数据的高可用性

转变业务以支持亚马逊的全链路压力测量

主要压力测量过程

上图是压力测量过程中存在的主要问题及改进。主要问题和优化过程如下：

-dockerbridge网络性能问题和网络中断si不平衡(优化：500-1000 TPS)-短连接导致的localport不足(优化后：1000-3000TPS)-生产环境下snat单核导致的网络延迟增加(优化后在测试环境下可达3000 TPS)-Spring MV CPath导致的CPU消耗过大(优化后：3000-4200TPS)-其他业务代码(如异常、代理等)的优化。)(优化后：4200 TPS)

护照部门的压力

由于用户进来后要先登录绑定账号，实际压力先去护照部分。在这个过程中，单机的TPS一开始只能达到500，经过N轮优化后基本可以达到5400TPS。下面主要讲一下这个优化过程。

Passport核心服务分为两部分：

Login主要处理登录请求。

Userservice处理登录后的业务逻辑，比如绑定优酷账号和淘宝账号。

为了更好地利用资源，每台计算机都配备了三个docker容器，运行在不同的端口(8081、8082、8083)上，通过桥接网络相互通信。

护照机的总体结构

注：这里的500TPS到5400TPS是指登录并绑定优酷账号和淘宝账号的TPS，这也是推广活动的主要瓶颈。

与用户服务网络相关的各种问题

过多的SocketConnect异常(如上所示)

还可以在userservice机器上通过netstat看到大量的SYN_SENT状态，如下图所示：

因为dockerbridge是用nat实现的，所以我们尽量去掉docker，让tomcat直接在物理机上运行。

此时，SocketConnect异常不再出现。

重组网络流程

docker(bridge)-短连接-访问淘宝API(淘宝openapi只能访问短连接)，性能差，cpu花在si上；

如果Docker(桥)-长连接到主机的一个代理(比如haproxy) -短连接-访问淘宝API，性能会更好。问题可能是短连接放大了Dockerbridge网络的性能损失。

当时看到的cpusi很高，截图如下：

去掉Docker后，性能有所提升。通过perftop继续查看内核状态，找到可用的LocalPort，需要占用大量CPU。gif动态截图如下(可以点击看高清图):

注意ipv6_rcv_saddr_equal和inet_csk_get_port占CPU的30%。

一般来说，一台机器可以使用3万多个LocalPort3。如果是短连接，默认一个连接释放后需要60秒恢复，30000/60=500，这是大概的理论TPS值。

同时观察这个时候CPU主要花在sy上，理想肯定是希望CPU主要用在我们身上。截图如下：

Sy占CPU 30-50%，太不科学了。同时，通过netstat分析连接状态，我们确实看到了很多TIME_WAIT:

所以让PE修改re

优化到3000TPS后，在线压力测量将继续。

其实业绩又回到500了，好沮丧。其实一开始账号绑定很慢，Passport怀疑是不是taobaoapi压力大不稳定。程序员通常认为他们就是他们自己。

于是怀疑从优酷的机器到淘宝的机器中间链路上有瓶颈，但是需要设计方案来证明这个问题在链路上，要不各个环节都会认为自己没有问题的，当时Passport的开发也只能拿到Login和Userservice这两组机器的权限，中间的负载均衡、交换机都没有权限接触到。

在尝试过tcpdump抓包、ping等各种手段分析后，设计了场景证明问题在中间链路上。

设计如下三个场景证明问题在中间链路上：

压测的时候在userserviceping淘宝的机器；

将一台userservice机器从负载均衡上拿下来（没有压力），ping淘宝的机器；

从公网上非优酷的机器ping淘宝的机器；

这个时候奇怪的事情发现了，压力一上来**场景1、2**的两台机器ping淘宝的rt都从30ms上升到100-150ms，**场景1**的rt上升可以理解，但是**场景2**的rt上升不应该，同时**场景3**中ping淘宝在压力测试的情况下rt一直很稳定（说明压力下淘宝的机器没有问题），到此确认问题在优酷到淘宝机房的链路上有瓶颈，而且问题在优酷机房出口扛不住这么大的压力。于是从上海Passport的团队找到北京Passport的PE团队，确认在优酷调用taobaoapi的出口上使用了snat，PE到snat机器上看到snat只能使用单核，而且对应的核早就100%的CPU了，因为之前一直没有这么大的压力所以这个问题一直存在只是没有被发现。

于是PE去掉snat，再压的话TPS稳定在3000左右

到这里结束了吗？从3000到5400TPS

优化到3000TPS的整个过程没有修改业务代码，只是通过修改系统配置、结构非常有效地把TPS提升了6倍，对于优化来说这个过程是最轻松，性价比也是非常高的。实际到这个时候也临近双11封网了，最终通过计算（机器数量*单机TPS）完全可以抗住双11的压力，所以最终双11运行的版本就是这样的。但是有工匠精神的工程师是不会轻易放过这么好的优化场景和环境的（基线、机器、代码、工具都具备配套好了）

优化完环境问题后，3000TPS能把CPUUS跑上去，于是再对业务代码进行优化也是可行的了。

进一步挖掘代码中的优化空间

双11前的这段封网其实是比较无聊的，于是和Passport的开发同学们一起挖掘代码中的可以优化的部分。这个过程中使用到的主要工具是这三个：火焰图、perf、perf-map-java。相关链接：http://www.brendangregg.com/perf.html;https://github.com/jrudolph/perf-map-agent

通过Perf发现的一个SpringMVC的性能问题

这个问题具体参考我之前发表的优化文章http://www.atatech.org/articles/65232。主要是通过火焰图发现springmappingpath消耗了过多CPU的性能问题，CPU热点都在methodMapping相关部分，于是修改代码去掉spring中的methodMapping解析后性能提升了40%，TPS能从3000提升到4200.

著名的fillInStackTrace导致的性能问题

代码中的第二个问题是我们程序中很多异常（fillInStackTrace），实际业务上没有这么多错误，应该是一些不重要的异常，不会影响结果，但是异常频率很高，对这种我们可以找到触发的地方，catch住，然后不要抛出去（也就是别触发fillInStackTrace)，打印一行error日志就行，这块也能省出10%的CPU，对应到TPS也有几百的提升。

部分触发fillInStackTrace的场景和具体代码行（点击看高清大图）：

对应的火焰图（点击看高清大图）：

解析useragent代码部分的性能问题

整个useragent调用堆栈和cpu占用情况，做了个汇总（useragent不启用TPS能从4700提升到5400）

实际火焰图中比较分散：

最终通过对代码的优化勉勉强强将TPS从3000提升到了5400（太不容易了，改代码过程太辛苦，不如改配置来钱快）

优化代码后压测tps可以跑到5400，截图：

最后再次总结整个压测过程的问题和优化历程

-dockerbridge网络性能问题和网络中断si不均衡（优化后：500->1000TPS)-短连接导致的localport不够（优化后：1000-3000TPS）-生产环境snat单核导致的网络延时增大（优化后能达到测试环境的3000TPS）-SpringMVCPath带来的过高的CPU消耗（优化后：3000->4200TPS)-其他业务代码的优化（比如异常、agent等）（优化后：4200->5400TPS)

整个过程得到了淘宝API、优酷会员、优酷Passport、网络、蚂蚁等众多同学的帮助，本来是计划去上海跟Passport的同学一起复盘然后再写这篇文章的，结果一直未能成行，请原谅我拖延到现在才把大家一起辛苦工作的结果整理出来，可能过程中的数据会有一些记忆上的小错误。