“基于真实客户行为的云端压力测试和业务容量规划实例”

本篇文章3219字，读完约8分钟

云智慧产品总监陆兴海

在快速发展的网络业务中，产品开发、迭代和交付周期越来越短。 另外，由于it基础设施的广泛云化和第三方api接口的大量采用，基于以前流传的公司内部环境构建的压力测试方法和测试工具难以满足APP功能的可用性和容量规划的估计

公司应该如何为频繁的市场活动和产品的快速迭代进行比较有效和准确的压力测试呢？ 云压力测试专家、云智慧压力测量宝产品总监陆兴海分享的两个客户案例，希望能给公司的云压力测试和业务容量规划带来一些有价值的参考。

压测宝云压测客户示例1 :压测宝如何进行业务容量的测试和计划？

云智慧有做旅游和摄影服务平台的顾客可以举办活动，为这个活动制作特别的活动页面，客户可以在活动页面申请。 那么，系统能在短时间内承受多少客户合并呢？

这是活动运营和技术部门必须事先考虑的问题。 去年举办类似活动时，出现了顾客大量涌入而无法使用服务的情况，因此必须首先帮助顾客整理容量测试和计划的实务思路。

具体应该如何实施压力测量呢？ 这里分为几个环节。

[1]场景的明确化和测试脚本的准备

因为客户在注册时提交客户的姓名、手机号码、手机后提交申请即可，所以实际上客户申请注册只需要调用一个api界面即可完成。 这是一个比较简单的场景。

1、由于涉及手机的认证场景，不提供对应的api时，建议客户万能或暂时取消；

2、是否允许并注册多个手机号码。 如果允许我们利用固定参数进行传播，如果不允许，我们可以准备与手机号码对应的测试数据进行应对；

3、短时间内开始大量并发多发，客户自身是否有安全栅，如果有，需要将压力节点的ip加入白名单；

[2]压力模式

既然是容量检测，整体压力过程就是一个阶段性的过程，通常不上升是一条直线。 这是与客户一直强调的问题，压力测量的目的决不是压垮系统，压力测量的目的是通过不断增加的合并来客观判断系统在不同压力条件下的性能状况，基于此，定制如图所示施加压力的梯度压力模式

[3]压测点分布

以前流传的压力测试工具主要在内网产生压力，压力规模受限于物理设备和许可证数量，造成了准备周期长、价格高等问题。 云压力测量提供了可靠的分布式压力测量服务(压力测量点)，通过完全利用云的计算资源，突破了这一限制。

目前，云智能测量点来自云服务云主机( aws、ucloud、Alibaba云(阿里巴巴云)等)和云智能部署在全国各大idc核心机房的服务器，

[4]压测时间的设定

根据对系统的访问情况，通常建议客户在早晨进行压力测量。 在这种情况下，可以最大限度地减少对客户的影响，最大限度地减少常规客户访问对压力测量结果的干扰。 但是，这个测量时间的设定不是绝对的，需要结合具体的客户业务场景进行评价。

[5]测量数据的观察

基本参数明确后，可以根据预定的时间执行压力测量任务。 云压力测量可以进行秒级的数据收集和实时统计分解，随时调整压力。 随着压力的上升，可以动态地表现系统的性能数据。 在阶段性加压过程中，如果性能急剧下降或大量失误，则无需继续执行压力测量任务。 此时，可以中止任务或降低压力，确保对整个压力测量过程的控制。

与该客户进行比较，按照上述步骤进行压力测试后，通过相关测试结果的数据观察和判断，压力测试的结论如下

测试的注册界面在360同时顾客以下的情况下比较好，但同时顾客达到360-500的情况下性能不好。 更直接地说，该系统能够支持360个同时。 具体论证如下。

1、合并达到360后，失败明显增加，同时持续到任务结束；

2、同时达到420后，响应时间超过3000ms基准值，持续到最后；

3、每秒事务数( tps )稳定在130左右，比较好；

这次测量的概要数据如下图所示。

如图所示，压力测试综合报告下图所示，并发客户数达到360时，系统开始出现大面积失败( 280点一次失误)，同时失败问题在压迫测试结束之前没有得到改善，但在测试的整个过程中没有断言不匹配，准确性良好，并且

事务处理响应时间趋势:随着APP访问客户的数量增加，当并发客户达到420时，系统事务处理的解决时间也大幅上升(超过基准值3000ms毫秒)，响应时间此后一直没有下降。

事务处理解决的性能趋势:压力稳步上升后，APP事务处理解决能力稳定，几乎维持了每秒130件左右的事务处理。 这个数值几乎保证了同时客户注册的诉求。

(/s2/)压测宝云压测客户示例2 )基于压测的后端性能问题的分析和定位)/s2/) )。

接下来，我们将介绍另一个客户的真实诉求场景。 在这里，我们将重点分析客户在压力测试中遇到的性能问题。 首先，从失败和响应时间慢这两个立场出发，首先是失败的状况。 如下图所示，是失败的类型及其占有率。

整个测试流程系统发生了各种类型的服务解析错误，从5点05分开始逐渐增加，从而导致事务解析失败。 具体的错误消息如下

502 )错误网关)5:43~5:46共112次502次错误)；

600 :连接异常、5:05~5:50共计264次600错误；

601 :插座异常(5:31和5:47发生2次601错误)；

603 )拒绝服务错误(从5:21到5:49共计48次603错误)；

其实是响应时间的分解，如下图所示表示某个事务处理及其对应的请求情况。

由上图可见，朋友的动态平均事务请求响应时间为10，862 ms，是其他APP请求的平均响应时间的7倍(其他请求的平均响应时间为1，400 ms )。

上面的照片是从新闻体育系统获取的朋友动态交易请求响应日志，可以看到响应时间为12232ms毫秒，其中连接时间为3136ms毫秒，请求被返回的副本非常大。 ( 51764字节)。 和其他APP相比，朋友的动态APP很花时间，阅读体验很差。

在此次测试的整个过程中，基于云智慧的APP性能管理产品透视淘宝进一步分析后端性能状况，通过对后端APP需求的分析，可以看到一定时期内web APP解决事务需求的响应时间、请求数量以及详细的请求新闻和变化趋势 同时顾客超过200时，响应时间明显变慢，但系统整体响应时间正常(解决时间不足500ms，为74.13% )；

然后，利用透视宝的代码级堆栈对齐分解功能，如下图所示，进一步分解数据库sql的情况。

后端的重要事务快照表明，单个请求可解决的数据库连接时间为1400.92ms毫秒，占95.23% (总响应时间为1471.02ms毫秒)，是最重要的数据库时间来源。

数据库查询操作所需的时间占3.71%，可以看到它是数据库的第二个耗时源，并且许多数据库查询sql语句的大部分查询条件都相同，对于高并发客户查询，性能优化/ [

基于以上分解，建议客户从以下方面进行优化。

1 )如果APP解决方案门户有前置负载均衡服务器，建议优化负载均衡服务器相关参数，提高客户请求门户的解决能力，并对负载均衡服务进行性能监测，及时发现系统瓶颈

2 )由于在解决事务请求的过程中数据库连接需要一些时间，因此建议使用数据库连接池组件来优化性能

3 )为了减少与后端数据库的连接次数，提高数据库查询的效率和性能，建议在系统架构中添加数据库缓存，解决并优化类似的sql操作。

根据对请求的详细分解，向调配宝提供问题请求的详细快照，包括请求的响应时间分解、请求标头和回复结果，如下图所示。

另外，如上所示，在压测宝的一次要求跟踪部分中集成了性能管理产品的透视宝，如下图所示，一次要求就可以直接看到后端的代码问题。

细分分解失败、低速、错误的事务和请求。 这包括错误类型分解、请求显示快照、后端详细配置等。

上面是两个实际应用场景云端压力测试的分解实例，通过性能压力测试(压力测量宝)，可以清楚地知道业务容量规划，系统中影响业务的性能问题)要求慢、失败。 通过与APP性能管理(透视宝)集成，找出并诊断根本问题，深入分析后端性能瓶颈，提高业务质量，实现APP应用的快速优化和在线化。

来源：UI科技日报