谈谈性能基线
一、背景与说明
1.1、性能基线的背景与意义
当系统的操作响应时间超出了用户可接受的程度，说明系统出现了性能问题，需要技术人员对系统进行优化，但是 “用户是否可接受”是一个主观的无法直接测量的标准，具体在何种程度下需要开启对系统性能的优化工作，又优化到何种程度后可以终止工作，没有统一的度量标准。
另外，真正引起性能问题的原因不仅仅是程序代码，也可能是承载系统运行的计算资源不充足，那么如何让性能优化人员明确目前到底是应该扩充计算资源还是修改程序代码，也需要有统一的指导标准和原则。
在这些问题背景下，性能基线就显得十分必要。性能基线的含义就是在可控的标准化的环境下，通过测试工具采集和人工分析后得出的有参考价值的指标数据。概括的来说，这些指标数据的主要作用如下：
1.为容量规划确定系统和应用程序的极限；
2.为配置测试的参数和配置选项提供参考依据；
3.为验收测试确定系统是否具备自己所宣称的能力；
4.为性能基线的建立提供长期的数据统计来源以及比较基准。
1.2、预期读者与目标
系统架构师或技术负责人：依照系统性能需求，参照性能基线测算计算资源需求；
性能测试人员：了解性能基线指标值，能够在测试环境中计算资源不充足的情况下，也对系统的性能表现进行测试并把关，明确系统性能是否达到基线要求，性能测试是否可以通过；
性能调优人员：为性能调优建立目标，只有系统性能表现满足基线指标值，方可完成性能调优工作。
1.3、性能基线指标选择
1.3.1、性能指标相关名词解释
QPS：每秒请求处理量(Query
Per
Second)，是对一个特定的应用系统在规定时间内所处理流量多少的衡量标准。通俗讲即，每秒钟处理完请求的次数，注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果；
事务（Transaction）：一组请求，事务的开始和事务的结束在录制压测脚本时定义，事务中包含的请求视具体业务场景而定，故事务中请求的数量无法固定有多有少。例如：用户登录作为一个事务，里面包含了登录页面加载、登录验证请求、首页面菜单数据请求、消息提醒请求、元件页面加载请求等多个服务器请求；
并发：系统能同时处理的事务数，在loadrunner压测工具里，并发一般指设置的并发用户数Vuser的数量；
TPS：Transaction
Per Second，每秒钟系统可执行完成的事务的数量。
并发、QPS、TPS间的关系：
QPS
= TPS*事务包含请求数量
并发数
= (QPS/事务包含请求数量)*事务平均响应时间
并发数
= TPS*事务平均响应时间
1.3.2、基线指标选择
一、为什么不使用并发作为性能基线指标？
在脱离了响应时间标准的情况下，单纯的并发量，只能反映系统承载压力，不能反映系统的性能表现，固只用并发来作为性能基线指标没有意义。
二、为什么不使用并发+响应时间（即TPS）作为性能基线指标？
项目上的性能需求描述往往是支持多少并发，响应时间在多少秒以内，这个完整的描述实际上就是TPS的要求。例如：500并发用户，响应时间不超过3秒，依照上文并发与TPS的换算公式，TPS指标要求极为500/3=166.6，即应用系统需要单秒处理166笔事务。
按上述，TPS确实可以反映出系统的性能表现，但考虑事务的多样性复杂性，TPS数值没有普适价值。压测TPS值会被测试场景事务的复杂度影响，实际举例：
有A、B两套系统，使用相同的硬件资源进行部署，A系统登录场景下，内部由10个请求构成，B系统登录场景，内部由15个请求构成，A系统压测结果有150TPS，B系统压测结果有100TPS，虽然A系统TPS值更高，但并不能说明A系统的性能表现比B系统好，因为B系统本身根据业务需要，场景复杂度更高，单事务对系统资源的需求也更高，TPS值比A系统低是合理的，故TPS也不能用来作为性能极限指标。
三、为什么要使用QPS作为性能基线指标？
请求作为构成服务器压力的原子单位，单位时间内处理请求数（QPS）相较上述指标来说，更易作为跨系统、不同硬件环境下性能对比的统一标准。
还是上述A、B系统为例，A系统场景10个请求，150TPS，换算为QPS为1500，B系统场景15个请求，100TPS，换算为QPS也是1500，虽然到请求级别，也会存在复杂度偏差，但基于统计与比较基准需要，可以认为A、B两套系统的性能表现持平或者是接近，并非A系统表现比B好很多。
四、还需要加入硬件资源的考量因素
上述A、B系统，假设前提是使用了相同的硬件资源条件，但是在实际情况下，不同系统部署使用的硬件资源是不一样的，如果A系统使用了更好的资源，性能表现优于B系统，也无法说明A系统的程序性能优于B系统。
故性能基线除了QPS值以外，还需要加入硬件资源的考量因素，最终性能基线的指标为：单位硬件资源（如单台应用服务器4核8G内存）下，系统压测的QPS极值。
二、性能基线测试
2.1、测试目的与策略
基线测试的目的是得到压测基础数据，便于后续推导出性能基线指标。
主要的测试策略：
1.构建可控环境，提供标准化的测试场景、测试工具和测试环境资源；
2.使用压测工具，测试同一场景，通过不断改变硬件资源投入，分别获得系统QPS极值。
2.2、测试准备
2.2.1、测试场景标准化
场景一、读数据场景
脚本概述：访问用户登录页，输入账户密码后，等待加载首页完，在个人消息中心里进行搜索(搜索条件为空)
，脚本中账户密码参数化500个账号。实际包含对一张数据量100万级别的数据表进行2次数据库查询操作。
压测场景：没有集合点和思考时间，模拟缓存压测，500并发
场景二、写数据场景
脚本概述：访问用户登录页，输入账户密码后，等待加载首页完，打开定制的压测页面，新增数据，脚本中账户密码参数化500个账号。实际包含一次百万级数据查询和一次删除、两次插入的数据库操作。
压测场景：没有集合点和思考时间，模拟缓存压测，500并发
2.2.2、计算资源标准化
本次测试环境为内网环境，千兆带宽
软硬件配置：
4台web服务器：Linux系统，4核8G，web应用基于Ecloud容器部署
Nginx服务器：Linux系统，4核8G，nginx基于Ecloud容器部署
Redis服务器：Linux系统，4核8G，redis基于Ecloud容器部署
Mysql服务器：Linux系统，8核32G，磁盘IOPS限制在5000
2.2.3、测试工具标准化
性能测试工具：Loadrunner11.0
2.3、测试结果
2.3.1、读数据场景测试结果
读数据场景，在单机web服务器cpu达到瓶颈时采集压测数据，后在集群模式下，通过水平扩展web服务器，直到扩展到4台web服务器，所有场景下都为web服务器CPU先到瓶颈。
测试结果数据：
| 测试条件 | 测试结果 | 服务器CPU | |||||||
| 系统架构 | 事务响应时间 | QPS（HPS） | Web1 | Web2 | Web3 | Web4 | Redis | Nginx | 数据库 |
| 单机部署 | 0.51s | 973.982 | 87.7% | 14.1% | |||||
| 两台集群 | 0.228s | 2092.321 | 88.6% | 84.3% | 11.9% | 13.1% | 32.8% | ||
| 三台集群 | 0.154s | 3107.397 | 93.2% | 89.2% | 88.6% | 18.5% | 20.1% | 40.3% | |
| 四台集群 | 0.125s | 3992.368 | 90.4% | 85.3% | 84.8% | 87.4% | 20.3% | 18.6% | 52.1% |
2.3.2、写数据场景测试结果
写数据场景，在单机web服务器cpu达到瓶颈时QPS为671，后在集群模式下，通过水平扩展web服务器，直到扩展到4台web服务器，所有场景下都为web服务器CPU先到瓶颈。
测试结果数据：
| 测试条件 | 测试结果 | 服务器CPU | IOPS | |||||||
| 系统架构 | 事务响应时间 | QPS（HPS） | Web1 | Web2 | Web3 | Web4 | Redis | Nginx | 数据库 | 数据库 |
| 单机部署 | 0.744s | 671.699 | 91.5% | 21.8% | 2221 | |||||
| 两台集群 | 0.406s | 1228.961 | 93.8% | 84.6% | 41.2% | 14% | 40.7% | 2687.5 | ||
| 三台集群 | 0.259s | 1933.576 | 94.6% | 92.8% | 94.1% | 51.7% | 17.8% | 52% | 3314 | |
| 四台集群 | 0.19s | 2627.384 | 95.2% | 89.6% | 87.9% | 88.7% | 58.5% | 23.9% | 59.8% | 3344 |
三、发现与结论
3.1、基础结论
就目前压测的两个场景：读数据、写数据，在web服务器cpu达到瓶颈的情况下，其他性能指标均未达到瓶颈的情况下，集群模式通过水平扩展web服务器，可实现处理性能（以QPS为衡量指标）线性增长；
单纯的读数据场景下，每增加一台4核8G服务器，系统QPS值提升1000左右；
单纯的写数据场景下，每增加一台4核8G服务器，系统QPS值提升650左右。
3.2、推论
基于上述数据，可得出基线指标的结论为：为F9框架系统部署提供硬件资源，每一个CPU核，可支撑系统性能表现QPS值在160~250之间，如果实际压测时，依照投入的资源情况，评测出系统性能表现低于此区间的，则认为性能达不到基线标准，需要进行系统调优。
四、补充说明
4.1、数据库磁盘IOPS为何限制在5000？
在本次性能基线测试中，预先对数据库服务器的磁盘进行了IOPS值的限制，限制值为5000。
一、为什么要限制IOPS？
因为根据实际项目经验，很多项目的没有特别强悍的数据库服务器，特别是磁盘IOPS，往往会成为系统瓶颈所在，本次测试通过限制IOPS值，也同步验证下F9框架在特定IOPS极限值下是否可以满足性能需求。
二、为什么限制在5000？
5000这个数值，也是根据性能调优人员经验确定。可认为，数据库服务器磁盘IOPS
5000是基本的硬件指标要求，如果低于此值，可以认为硬件条件不达标，难以满足大型项目高并发要求，需要调整数据库服务器资源投入。
另外，许多项目使用虚拟机作为数据库服务器，且使用共享磁盘，IOPS能力也被分占，往往达不到5000
IOPS的要求，所以在大型项目或对系统性能有一定要求的项目中，不推荐使用虚拟机作为数据库服务器。
4.2、通俗化的性能基线指标
由于目前的性能需求往往都是并发+响应时间这样的描述，并不能对应的了QPS值，无法指导计算资源评估，为了将性能基线通俗化，需要进行一下换算。考虑到事务复杂度不一，为了便于换算，统一预估单事务平均包含10个请求，单事务响应时间为3秒。基于单机器4核8G，QPS值为650~1000之间，依照换算公式“并发=QPS/单事务请求数*事务响应时间”，支撑并发量为195~300之间。故通俗化的基线指标为，单台4核8Gweb服务器，支持用户并发195~300间。按此，一个需要满足1000并发量要求的系统，大致需要4台4核8Gweb服务器。
