威海网站制作,如何自己做网站推广淘宝客,做直播的网站有哪些,平台运营是做什么的简介#xff1a; 全链路压测方案下#xff0c;非加密场景下至少有 70% 的性能提升#xff0c;加密场景下 10%的性能提升#xff0c;并在 MGS 扩容完成后可实现大幅的性能提升#xff0c;调优的结果远超预期。 业务背景
随着移动开发行业的步入存量时代#xff0c;App 整…简介 全链路压测方案下非加密场景下至少有 70% 的性能提升加密场景下 10%的性能提升并在 MGS 扩容完成后可实现大幅的性能提升调优的结果远超预期。 业务背景
随着移动开发行业的步入存量时代App 整体架构的负载能力、以及各个环节的优化逐步成为各个开发者们关注的重点。
压力测试就是实现以上功能的主要方案。一般可以基于压力测试
测试后端业务的负荷瓶颈评估整体架构性能业务稳定峰值排查出各节点的薄弱关系优化系统资源避免短板效应
为运营提供准确的用户承载量作为作证避免活动/新应用的上线带来的突发流量造成的用户体验不佳。
今天我们将为大家介绍全链路压测方案的是实现原理和实施路径。
全链路压测与原理
通常我们可以简单的把负载性能单机性能*机器总量这一公式套用到预估的方案中但是在实际的场景下常常会涉及到大量的业务节点如DNS网关数据库等环节都有可能是导致整体业务性能的瓶颈因而实际服务能力可能与预期存在较大误差。
一般用户会通过 loadrunner 等方案实现生产环境下的服务器性能压力测试但是在 mPaaS 应用中复杂的部署无法通过 MGS 网关高昂的费用等难点应运而生为了解决这些痛点。
mPaaS 团队这边依据多位客户的述求提供出 MGS 全链路压测方案。
区别于以往的测试方案全链路压测方案中最大的不同是视角上的不同站在客户端角度上作为切入点将整个服务端链路作为一个黑盒以真实的 request 和 response 作为评估的依据模拟真实的业务请求真实的数据流量真实的用户习惯来达到得出尽可能真实的评估结果。
链路梳理
在一个标准的数据链路中一般为以下模型 而在全链路压测中我们把整体的服务端实现视为一个黑盒因而我们所需关注的焦点聚焦在前半段重点可以概括为
1.客户端请求构建
2.客户端请求发送并通过 MGS 网关
3.客户端解析 MGS 网关返回的 response 并做出正确处理
4.实现高并发的客户端请求集群。
以上再次梳理可以归纳出以下难点
难点1 客户端请求构建
mPaaS 移动网关 RPC 通讯是在 HTTP 协议基础之上的实现的一种标准化接口方式在复用 HTTP 请求标准的前提下定义了一套数据交换格式采用HeaderBody 作为实际区分可以近似理解为通过Header 中的Operation-Type做为真实api指向将body部分依据规则封装后进行转发。
在该步骤中我们以 JMeter 作为实现方案Jmeter 灵活的脚本特性可以良好的实现客户端的真实请求模拟。
难点2 数据加解密
mPaaS 移动网关 RPC 请求特有的数据加密方式构建请求中比较复杂的部分。客户侧已有的测试方案不能覆盖这部分能力因此往往选择关闭网关服务端验签和加密功能实施压测。
这种方式的隐患在于无法估计加解密给网关服务器带来的计算压力。
根据经验不同的加解密算法配置对网关的吞吐量有 20% ~ 40% 影响。在此阶段由金融线 SRE 团队基于用户生产环境定制开发的 JMeter 插件 MGSJMeterExt该插件逆向实现了请求体的加密和解密过程使得压测脚本的编排可以包括加密部分。
难点3 请求签名构建
mPaaS 移动网关 RPC 请求特有的签名校验机制也比较特殊。同数据加解密一样目前客户侧无方案可覆盖这部分能力往往选择关闭接口验签进行测试。同样借助 MGSJMeterExt可以实现在 JMeter 中实现对报文的正确签名并通过服务端校验。
难点4 压测集群环境部署
对于压测来说需要的重点侧重于真实真实的流量入口真实的并发数量才能得出真实的结果而自行实现压测环境高昂的集群部署费用也成了不必要的开支.
因而我们推荐用户采用阿里云 PTS 作为压测平台基于其他方案具有部署简易支持 Jmeter 脚本流量真实等优势也可为用户提供更为详实的压测报告。
概览
以上模型简单可以归纳为以下结构 全链路方案及实施
Part1 前期准备及调研
在前期阶段目标是为了为实际的压测提供相关的准备和数据支撑确立压测目标和整体方向。
1.1 目标及数据准备
1.客户需要明确自身的压测目标和压测目的基于压测目标参照以往的运营数据给出涉及到的具体业务类目和可能的用户行为习惯在整体的业务中各习惯所带来的相关比重关系。
1.2 客户端准备
1.客户端这边需要依据相应的业务目标整理出在客户端实现中可能涉及到的接口和数据流程如是否包含前置步骤如登陆等是否包含强制的步骤如首页的刷新等通过抓包等收集该步骤中真实的 request 和 response以及确定符合预期的值条件。
2.该步骤涉及业务结构的不同亦可由服务端接口端完成该准备。
1.3 服务端准备
1.服务端这边依据1.2中统计的相关接口做好相关的数据挡板避免导致测试数据污染真实数据库。
2.由于在 mPaaS 全链路压测中服务端被视为黑盒因而需要实现对于服务端各业务的性能指标的监控为后期的服务端调优作为依据。
1.4 MGSJMeterExt 插件准备
由于 MGSJMeterExt 需要依据实际网关环境进行定制开发需要用户提供以下数据
1.工作空间相关环境数据
2.加密算法和公钥
QA答疑
Q如何实现压测脚本
A会由我们的专家团队和现场同学完成简单场景下的压测脚本培训在实际的场景下可能涉及到业务的多个环节如登陆 token 的获取一些明确的前置步骤这一类由于涉及到复杂的业务场景需要客户在阿里专家团队的协助下自行完成。
Q为什么是全链路的?
A虽然我们的压测脚本是基于客户端逻辑实现的但是我们实际上是模拟了真实的数据请求也会确认服务端的返回是否达到预期涉及到整个完整的数据链路及节点。
Q链路的指标如何实现埋点?
A压测方案的对象是基于黑盒的通过系统的 pts 指标请求参数与返回的回报率校验符合预期结果的成功率来确认基于用户角度下的整个架构所能负载的性能对于一些后端的指标由于不同的客户采用的服务端的架构存在不少的差异对于后端这类指标一般对应的服务商都能提供相关的监控方案也无需 mPaaS 这边进行处理。
Q为什么使用 PTS?
AmPaaS 团队实际上提供的是 MGS 的通讯解决方案协助客户完成 PTS脚本的编写并不强制使用 PTS只需要能提供相关的 Jmeter 集群部署环境即可且 PTS 相关资源需要用户自行采购但目前 mPaaS 团队基于多个案列评估相对而言使用 PTS有更高的性价比且能提供更为符合预期的压测环境完整的压测报告故推荐用户使用 PTS 进行压测。
Q有没有什么详细的标准如2c4g情况下或者4c8g下应该达到怎样的性能指标?
A压力测试本身即是为了明确在相关的系统资源下可以达到的性能指标由于服务端的架构不同实际业务涉及的流程节点不同不同环境下的性能存在着巨大的差异这些即是使用压力测试的目的需要通过压测才能明确真实的指标和评估各个节点的实际资源耗时。
Part2 Jmeter开发与脚本改造
我们归纳出了 MGS 通讯方案的特殊侧重点因而我们需要在 Jmeter 完成这几点的改造
2.1 Header 改造 在 Header 中我们需要注意以下几点
1.MGS 网关协议是依赖于一些 Header 字段的因而需要确保网关参数齐全。
2.部分参数为固定值可直接写死相关的配置可以参考控制台下载的配置文件。
3.如业务有其他的 Header 依赖如 cookide 等业务上需要使用也可直接添加MGS 网关不会对 Header 信息进行过滤。
2.2 Url改造 在 URL 中我们需要注意以下几点
1.URL 的实际指向应为 MGS 网关而非实际的业务服务器相关的配置可以参考控制台下载的配置文件。
2.目前所有到 MGS 网关的请求均为 post如有 get 请求也是由 MGS 进行转发时变为 get 的在与 MGS 的通讯中也为 post。
3.Body 部分如无特殊需求建议如图所示即可。
2.3 Request改造 在 Request 中我们需要注意以下几点
1.这里的加密/验签依赖于 MGSJMeterExt 文件需要引用该文件。
2.一般情况下仅需修改 //config 部分即可。
3.下述部分一般为统一方案主要为了实现加密和验签无需修改。
2.4 Response改造 在 Response 中我们需要注意以下几点
1.在这里考虑到施压机性能不会影响到服务端的评估能力因此若无数据二次使用需求或结果判断需求这里可不写
2.如有相关需求可在这里完成 Response 回参的二次处理
Part3 实际压测
大致的步骤可归纳为 3.1 PTS 及脚本性能调优
阿里云性能测试服务PTS提供了方便快捷的云端压测能力在本次压测服务中借助 PTS 实现互联网压力流量的输入。
有意思的点在于加解密计算不仅给网关带来计算压力也会给施压机带来了一定的计算压力。因此第一个版本的插件和压测脚本在实施前我们首先进行了针对试压机进行了的“压力测试”。
第一轮基础测试
PTS 试压机配置
1.PTS 单 IP 单元配置
2.并发数 500单机最高并发
3.固定压力值流量模型
4.两分钟压测时常
从回收的压测报告看TPS 结果并不高但返回 RT 值并不高 接下来观察施压机的性能表现可以看到施压机的 CPU 使用率水位一直比较高因此有理由怀疑加密计算压力给施压机的压力释放带来比较大的影响。 通过对重复内容加密结果的缓存大幅降低了计算压力同时为了避免缓存设计引起内存问题对缓存上限进行了限制。
第二轮测试
与第一轮的测试配置完全相同仅更换了优化后的加密插件。从回收的测试报告看场景 TPS 有 75% 的提升 从施压机 CPU 性能看有一个明显的优化。 第三轮测试
有了第一轮的摸底和第二轮的优化情况第三轮测试在配置上使用两台施压机满负荷进行压测观察压测结果 从结果看压测脚本和编排过程符合预期可以在客户生产环境进行正式的 PTS 云端压测。
3.2 生产环境压测摸底
在正式压力测试开始进行了若干轮小规模的压力测试观察后端系统的工作状态是否符合预期。摸底期间发现如下问题
问题一Nginx流量转发不均
从MGS容器的日志表现上看部分容器始终获取不到任何请求经过排查发现该问题由三个原因导致
1DMZ区Nginx转发配置少配了一个MGS容器IP
2DMZ区到每一个MGS容器IP的网络策略均需要开通访问权限
3Nginx转发规则设置为iphash在单IP来源的测试情况流量仅能转发到一个容器上。
配置了正确的IP列表、开通了网络权限以及修改转发规则后该问题得到解决。
问题二特定 MGS 容器基础 CPU 负载过高
前期测试发现有一台 MGS 容器mpaasgw-7在静默状态下的 CPU 负载在25%不符合预期。
登录容器发现存在一个 JPS 进程消耗了大量的 CPU。怀疑是前期调测阶段调用后未正常释放。杀掉JPS进程后问题解决为了避免其他问题一并重启了该容器
注JPS, Java Virtual Machine Process Status Tool)是java提供的一个显示当前所有java进程pid的命令参见https://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html 。
问题三CoreWatch 监控平台无法访问
CoreWatch 控制台无法访问浏览器中报 502 错误。重启 CoreWatch 容器后页面可以加载但始终处于加载中状态。
http://corewatch.*.com/xflush/env.js 一直处于pending状态。排查发现 ALB 实例监听配置存在错误修正后问题得到解决。
3.3 生产环境压力测试总结
在解决了 3.2 中的所有问题后系统具备了压力测试的条件正式压测会针对“加密场景”和“非加密”场景分别做压力测试。
由于生产数据不做外泄以下仅对遇到的问题进行一些例举。
“加密”情况下测试
1.压测时发现在并发数 500 左右即出现 TPS 不做增长代表着可能到达了瓶颈。
2.观察 MGS 网关容器的负载情况整体 CPU 负载达到极限。
3.同一时间段的 MCUBE 容器 CPU 负载情况健康其他性能指标IO、网络等也处于健康状态。
4.从上述情况看加密场景下主要性能瓶颈在 MGS 网关上根据经验及流程分析主要性能压力由报文加解密过程中的密集计算所带来。要解决这一瓶颈需要对 MGS 容器进行扩容。
“不加密”情况下的测试
1.TPS 的增长在并发达到 1000 左右时停止增长。一般情况下这种情况说明触及了系统容量的瓶颈。
2.观察 MGS 网关容器的负载情况与加密情况下的情况不同此时整体 CPU 负载均不高。
3.与此同时根据网络组的反馈压测期间互联网到 DMZ 区的 TCP Session数量是 DMZ 区到内网区的3~4倍交易内网段的防火墙 CPU 压力较高。
4.结合上述三种表现怀疑触及网络层面瓶颈。根据现场情况发现DMZ 区 Nginx 转发到内网时没有采取长连接保持策略。修改Nginx配置添加keepalive 1000配置重新进行第二轮测试。
关于参数Keepalive说明默认情况下Nginx访问后端都是用的短连接HTTP1.0每一个新的请求Nginx 都会新开一个端口和后端建立连接后端执行完毕后主动关闭该链接。Keepalive参数会告知Nginx和后端服务器之间缓存的长连接数量当新的请求进来时可直接复用TCP连接减少建立TCP连接所带来的性能影响。参见http://nginx.org/en/docs/http/ngx_http_upstream_module.html。
总结
在上述问题优化后非加密场景下至少有 70% 的性能提升加密场景下 10%的性能提升并在 MGS 扩容完成后可实现大幅的性能提升调优的结果远超预期。
本文作者阿里云 mPaaS TAM 团队王泽康北默东雷荣阳
原文链接
本文为阿里云原创内容未经允许不得转载。
