性能测试准备过程总结

准备阶段

必要性分析

分析是否有必要进行性能测试；

被测对象分析

确认被测对象，并根据被测对象性质确认测试方案；

测试技术准备

根据被测对象准备测试技术不一样协议测试工具、测试重点及方案是有区别的，例如http接口、rpc、websocket、udp测试技术不一样，应根据不一样的测试对象准备不一样的测试方案

目标评估

评估被测服务性能指标预期结果

峰值QPS

已上线的需求能够按目前线上状态评估，这样最准未上线的需求一种方式能够找相似其它功能，没有类似功能的话能够找相似其它产品没法参照的话可按全量工具评估总请求，平均到秒后再按“帕累托法则（八二法则）”乘以对应系数估算

• QPS

大部分单一接口的QPS=HPS，一条请求就是一次query，有少部分需求可能一次Hit有屡次Query，需了解具体业务实现

• TPS

复杂业务评估指标可以使用TPS（每秒处理事务数），常见的状况像一次转帐业务可能包含查询、转帐、核对等几个连续动做，这种连续动做可称为一次T，TPS常常用来评估逻辑处理的能力和用时；

响应时间

不一样产品对响应时间的要求是不相同的，内存处理通常请求的响应时间应该在10ms之内，有数据库读写的状况可能稍长（redis通常是十毫秒级别，mongo稍长，mysql最长，但通常大小的数据也应该在百毫秒级别）超过百毫秒的状况须要确认具体需求，及这类状况占比，响应时间指标通常有下面几种级别；

• 平均响应时间

总时间/总请求数

• TP50

全部请求中处理最快的前50%请求中的最长耗时

• TP90

全部请求中处理最快的前90%请求中的最长耗时

• TP95

全部请求中处理最快的前95%请求中的最长耗时

• TP99

全部请求中处理最快的前99%请求中的最长耗时

• TP999

全部请求中处理最快的前99.9%请求中的最长耗时

• 错误响应数占比

全部请求中非200返回码的请求数占比

• 超时率

全部请求中超时的请求数占比需在压测工具中定义一个超时时间

被测服务资源占用指标预期

• 服务器cpu预期

程序有大量运算的状况下cpu可能成为瓶颈，例如dsa加密、大量检索运算；

• 服务器内存预期

一、程序启动时须要load大量数据到内存；二、程序运行时须要使用大量内存以增长处理速度（空间换时间）的状况；

• 存储预期

绝大多数的web服务存储开销都在log等功能需求上，且通常状况log文件会定时传走&清理，这里要注意清理过程是否会存在log积压；

• 带宽预期

通常过大的静态资源应放在专用的资源服务器上，带宽问题常见于大量数据资讯返回或流媒体服务中；

• 端口数预期

端口问题常见于长链接服务，和须要做为client端向子服务请求的需求；常见问题：一、time_wait过多；二、服务阻塞致使端口没法释放；

• 磁盘io预期

磁盘io问题常见于写log的功能，业务逻辑中须要作磁盘io的需求已经很少了，由于数据在程序启动时会被加载到内存中以提高读写速度；

相关依赖预期评估

• 依赖后端子服务

处理一个请求时须要向一个或多个后端服务请求资源；

• 依赖后端DB

处理一个请求时须要作db读写操做；

• 依赖运行环境，例如K8S集群等

服务运行的环境可能致使性能不知足预期，例如当服务部署在虚机时，须要评估虚机处理能力；若是部署在k8s集群时，需评估宿主机和集群前端proxy处理能力；如请求流包含多个环节时，每一个环节都有压力存在；

• 依赖外部资源，例如CDN服务等

场景：业务逻辑回返回cdn地址，客户端收到地址后直接去cdn获取数据；这类场景须要对cdn服务的处理能力和带宽预期作评估；

• 依赖磁盘空间，例如log存储

评估服务日志量大小；

• 其它意想不到的依赖

场景：百度春晚红包需求，百度红包服务端性能符合预期，但整理逻辑中忽略了用户习惯（用户对百度的认知是搜索引擎而不是app，因此app的红包功能对百度网页搜索带来了很是大的并发流量）致使搜索引擎主站瘫痪；百度红包功能还对第三方app市场和appstore带来大量流量，致使其服务瘫痪；

测试方案

测试方案应包含如下内容

被测对象（即性能测试需求中的功能-子功能）

测试目标

有预期的状况：经评估的各个指标预期预期不明确的状况：说明状况，例如“此功能没法预估预期qps状态，上线后根据实际状况调整”

测试环境

说明测试所用机器各项配置；

依赖说明

说明被测服务依赖的服务及功能的状态或mock状态

实验分组及排期

每组的验证点及环境、时间安排；

测试工具

http接口工具

• loadrunner

• locust

• jmeter

• wrk

grpc工具

• ghz

流量复制放大回放

• goreplay

websocket长链接

• websocket-bench

其它自定义协议等

• 本身编写压测脚本

可以使用go语言或python gevent库等方案模拟大并发

测试用例

测试用例要覆盖全部逻辑，能够经过统计压测用例覆盖率的方法来肯定是否有遗漏逻辑；需评估未覆盖的代码逻辑是否须要补充用例；

测试环境

测试环境要尽可能与线上保持一致；不能保持一致的可选择性能比线上少低一点的机器；若是服务是第一次上线，建议在不影响线上其它服务的状况下（外围有线上proxy，或须要读写线上数据库等相似状况不能直接使用测试环境进行性能测试）直接只用线上环境进行性能测试；

子服务&测试配置准备

测试中台服务时须要准备与生产环境一致的子服务或微服务，没有条件准备时可以使用mock服务替代；

风险预案

对重要的被测系统应该作planB，例如：一组服务为节省资源，使用8台服务器，评估可知足需求；但可能存在短时大并发的状况，因此，在上线之初或有运营活动以前，应准备一些备用机，当线上监控报出问题时，马上扩容；