京东物流性能测试理论梳理 ——性能测试的正确打开方式

京东全球年中购物节火热进行中，2018年6月1日0点到6月18日24点累计下单金额达1592亿元，出库订单金额同比增长超过37%！618期间，90%以上自营订单实现当日达或次日达。在这要为物流研发系统高性能、高稳定点赞！这离不开备战阶段必做的一件事：对系统持续压测和优化。你的系统做了吗？

性能测试的正确打开方式，现在开始~

>>不可不知的性能测试二三事

>>新手性能测试如何开展？

不可不知的性能测试二三事

1.1 性能测试是什么？

通过模拟真实用户行为设计不同场景组合，并参考历年线上数据量，测试系统是否满足性能要求和发现系统问题并进行调优。

1.2 常见性能指标

吞吐量：单位时间内服务器处理客户请求的数量，常用TPS表示，即Transactions Per Second。

响应时间：端到端时间，即客户端发出请求开始，到客户端收到所有数据所消耗的时间，通常关注业务的平均响应时间和TP99，TP99表示99%的请求在此时间内。

并发用户数：同一时刻与服务器进行数据交互的所有用户数量。

1.3 TPS与响应时间的误会？

如接口一次调用响应时间100ms，那么每秒钟可调用10次，由此可知接口的TPS=10次/秒?

多次听到这样的推断过程，我们再仔细思考下：应用通常是多线程并发处理，线程之间也存在资源争用等问题。响应时间和TPS存在相关性，但不是简单的线性关系。

1.4 性能指标之间关系？

上图是典型的并发用户数、TPS（吞吐量）、响应时间和系统资源关系模型：

（1）系统无瓶颈时：并发用户数↑，TPS↑，系统资源↑，业务响应时间无明显增长；

（2）系统达到瓶颈时：并发用户数↑，TPS↓，系统资源维持较高水平，业务响应时间明显↑。

1.5 性能测试时机

性能测试的时机很重要！一般而言，只有在系统基础功能测试完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

新手性能测试如何开展？

这里重点说明性能测试最核心的流程，帮助大家快速上手项目，其他流程也很重要，请大家持续探索。

2.1 需求调研

需求是性能测试的起始点，明确测试目的和指标,指引性能测试正确实施。

2.1.1 需求分析

（1）根据项目背景，从性能领域分析测试目的：

（2）用户场景剖析和业务建模：根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，获得系统的典型业务高峰期调用情况，例如：选择高峰期调用量Top10业务，作为本次压测的内容。

2.1.2 量化性能目标

根据本次性能测试的应用领域结合系统的业务特点，由业务模型推到测试模型，量化性能测试指标，如：

（1）10分钟接单60万，即TPS=60万/10分钟=1000单/秒；

（2）接单接口响应时间不超过50ms；

（3）应用服务器CPU<60%，数据库磁盘disk busy<40%等。

2.1.3 测试方案

主要明确测试目的、测试计划、测试环境、测试用例、性能指标等。

2.2 测试准备

2.2.1 测试环境

测试环境包括：硬件环境、操作系统、应用服务等组成。搭建测试环境原则：与生产环境软硬件、服务版本、参数配置保持对应。同时保持测试环境的干净和稳定，不受外来因素影响。

例如线上评估型压测：可在预发布环境测试，准备一个压测分组。

2.2.2 压测工具及测试脚本

针对京东业务常见的JSF接口，我们研发了一套极简压测工具，实现：场景设计、生成脚本、发送压力、性能监控及结果收集。

提供一下接口基本信息就可轻松做压测。

压测工具同样支持HTTP协议快速压测。

2.3 测试执行

2.3.1 测试执行

初次性能测试会遇到疑问？并发用户数设置多少合适？应该执行多长时间？

执行步骤介绍：

1.验证测试：

验证被测业务调用成功，脚本开发正确；

并发用户数=1  执行次数=1；

接口返回值正确，断言成功。

2.基准测试：

并发用户数=1，执行次数=100 或 执行时间=10分钟

3.负载测试：

用户数的设置：按固定步长增加并发用户数，直到系统达到瓶颈；

并发用户数步长可根据系统业务和经验确定，如：

情况一：用户数=10，CPU=20%，此时每轮压测可以10个用户递增，1 10 20 …

情况二：用户数=10，CPU=5%,此时每轮压测可以考虑以30个用户递增，1 30 60…

根据测试结果分析，适当增加、删除压测轮次。

执行时间=10分钟

4.稳定性测试：

给系统加载一定压力，使系统运行一段时间，检查系统的稳定性，一般测试时间N*12小时，系统压力一般设置为最大吞吐量的80%。

以上为测试执行基本步骤，根据测试目的的不同，适当增减。

2.3.2 性能监控

性能监控通用的监控有业务性能指标（TPS、TP99、Users）、服务器硬件性能指标（CPU、MEM等），其他监控与系统架构相关，例如：JVM、DB、JimDB等。

京东有非常完善的监控平台：UMP平台、MDC平台、JimDB监控平台等，Qone压测工具可以将业务性能指标、服务器资源监控汇总到一起，一站式观察性能过程指标。

2.3.3 执行结果

执行完测试后，对结果进行整理分析，是否满足需求调研时明确的指标。

上图是某接口的性能结果，并发用户=25，此业务达到最佳TPS=13957，TP99=10ms，CPU=88%，判断此时是否达到预期目标。(并发用户数=30时，TP99从10ms到20ms增大200%，TPS从13957到14530,只增长4%，系统明显存在瓶颈)。

2.3.4 性能调优

下面是一个典型的系统架构图：

影响性能的因素很多，硬件设备、网络、数据库、应用程序等，根据经验或由外及里（硬件资源、网络到程序代码级别）顺序排查系统瓶颈产生的原因，有针对性的进行优化。

2.4 测试报告

测试结果是否满足测试目标，测试过程数据，调优过程及前后性能对比。

某系统性能测试报告示例：

XX系统性能测试报告

性能测试结论

线上压测集群，数据库一主五从结构，混合业务场景总TPS=459次/秒，满足预期指标333次/秒。

此时web服务器CPU= 52%，数据库主库CPU=8%，disk busy=11%，数据库从库CPU=4%，disk busy=2%。

稳定性测试：应用服务器 CPU=30%时，持续压测12小时，系统未出现异常。

测试详细数据

调优事项

风险与问题

测试环境

应用服务器：压测集群

数据库：一主五从

干货小结：

分享一些性能测试的感悟，希望对大家有所帮助：

（1）任何脱离需求的性能测试都是耍流氓；

（2）性能调优不一定要一步到位，从40s到10s就是一次性能调优；

（3）平衡性能优化和调优成本；

（4）接受合理误差可以省去很多麻烦；

（5）性能测试离不开技术、管理、沟通。

---------------------END---------------------