谈谈性能基线

1、背景与说明

1.一、性能基线的背景与意义

  当系统的操做响应时间超出了用户可接受的程度，说明系统出现了性能问题，须要技术人员对系统进行优化，可是 “用户是否可接受”是一个主观的没法直接测量的标准，具体在何种程度下须要开启对系统性能的优化工做，又优化到何种程度后能够终止工做，没有统一的度量标准。 
  另外，真正引发性能问题的缘由不只仅是程序代码，也多是承载系统运行的计算资源不充足，那么如何让性能优化人员明确目前究竟是应该扩充计算资源仍是修改程序代码，也须要有统一的指导标准和原则。 
  在这些问题背景下，性能基线就显得十分必要。性能基线的含义就是在可控的标准化的环境下，经过测试工具采集和人工分析后得出的有参考价值的指标数据。归纳的来讲，这些指标数据的主要做用以下： 
  1.为容量规划肯定系统和应用程序的极限； 
  2.为配置测试的参数和配置选项提供参考依据； 
  3.为验收测试肯定系统是否具有本身所宣称的能力； 
  4.为性能基线的创建提供长期的数据统计来源以及比较基准。

1.二、预期读者与目标

  系统架构师或技术负责人：依照系统性能需求，参照性能基线测算计算资源需求； 
  性能测试人员：了解性能基线指标值，可以在测试环境中计算资源不充足的状况下，也对系统的性能表现进行测试并把关，明确系统性能是否达到基线要求，性能测试是否能够经过； 
  性能调优人员：为性能调优创建目标，只有系统性能表现知足基线指标值，方可完成性能调优工做。

1.三、性能基线指标选择

1.3.一、性能指标相关名词解释

  QPS：每秒请求处理量(Query Per Second)，是对一个特定的应用系统在规定时间内所处理流量多少的衡量标准。通俗讲即，每秒钟处理完请求的次数，注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果； 
  事务（Transaction）：一组请求，事务的开始和事务的结束在录制压测脚本时定义，事务中包含的请求视具体业务场景而定，故事务中请求的数量没法固定有多有少。例如：用户登陆做为一个事务，里面包含了登陆页面加载、登陆验证请求、首页面菜单数据请求、消息提醒请求、元件页面加载请求等多个服务器请求； 
  并发：系统能同时处理的事务数，在loadrunner压测工具里，并发通常指设置的并发用户数Vuser的数量； 
  TPS：Transaction Per Second，每秒钟系统可执行完成的事务的数量。 
  并发、QPS、TPS间的关系： 
    QPS = TPS*事务包含请求数量 
    并发数 = (QPS/事务包含请求数量)*事务平均响应时间 
    并发数 = TPS*事务平均响应时间

1.3.二、基线指标选择

1、为何不使用并发做为性能基线指标？ 
  在脱离了响应时间标准的状况下，单纯的并发量，只能反映系统承载压力，不能反映系统的性能表现，固只用并发来做为性能基线指标没有意义。

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也不能用来做为性能极限指标。

3、为何要使用QPS做为性能基线指标？ 
  请求做为构成服务器压力的原子单位，单位时间内处理请求数（QPS）相较上述指标来讲，更易做为跨系统、不一样硬件环境下性能对比的统一标准。 
  仍是上述A、B系统为例，A系统场景10个请求，150TPS，换算为QPS为1500，B系统场景15个请求，100TPS，换算为QPS也是1500，虽然到请求级别，也会存在复杂度误差，但基于统计与比较基准须要，能够认为A、B两套系统的性能表现持平或者是接近，并不是A系统表现比B好不少。

4、还须要加入硬件资源的考量因素 
  上述A、B系统，假设前提是使用了相同的硬件资源条件，可是在实际状况下，不一样系统部署使用的硬件资源是不同的，若是A系统使用了更好的资源，性能表现优于B系统，也没法说明A系统的程序性能优于B系统。 
  故性能基线除了QPS值之外，还须要加入硬件资源的考量因素，最终性能基线的指标为：单位硬件资源（如单台应用服务器4核8G内存）下，系统压测的QPS极值。

2、性能基线测试

2.一、测试目的与策略

  基线测试的目的是获得压测基础数据，便于后续推导出性能基线指标。 
  主要的测试策略： 
    1.构建可控环境，提供标准化的测试场景、测试工具和测试环境资源； 
    2.使用压测工具，测试同一场景，经过不断改变硬件资源投入，分别得到系统QPS极值。

2.二、测试准备

2.2.一、测试场景标准化

场景1、读数据场景 
  脚本概述：访问用户登陆页，输入帐户密码后，等待加载首页完，在我的消息中内心进行搜索(搜索条件为空) ，脚本中帐户密码参数化500个帐号。实际包含对一张数据量100万级别的数据表进行2次数据库查询操做。 
  压测场景：没有集合点和思考时间，模拟缓存压测，500并发

场景2、写数据场景 
  脚本概述：访问用户登陆页，输入帐户密码后，等待加载首页完，打开定制的压测页面，新增数据，脚本中帐户密码参数化500个帐号。实际包含一次百万级数据查询和一次删除、两次插入的数据库操做。 
  压测场景：没有集合点和思考时间，模拟缓存压测，500并发

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.三、测试工具标准化

  性能测试工具：Loadrunner11.0

2.三、测试结果

2.3.一、读数据场景测试结果

  读数据场景，在单机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.二、写数据场景测试结果

  写数据场景，在单机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、发现与结论

3.一、基础结论

  就目前压测的两个场景：读数据、写数据，在web服务器cpu达到瓶颈的状况下，其余性能指标均未达到瓶颈的状况下，集群模式经过水平扩展web服务器，可实现处理性能（以QPS为衡量指标）线性增加； 
  单纯的读数据场景下，每增长一台4核8G服务器，系统QPS值提高1000左右； 
  单纯的写数据场景下，每增长一台4核8G服务器，系统QPS值提高650左右。

3.二、推论

  基于上述数据，可得出基线指标的结论为：为F9框架系统部署提供硬件资源，每个CPU核，可支撑系统性能表现QPS值在160~250之间，若是实际压测时，依照投入的资源状况，评测出系统性能表现低于此区间的，则认为性能达不到基线标准，须要进行系统调优。

4、补充说明

4.一、数据库磁盘IOPS为什么限制在5000？

  在本次性能基线测试中，预先对数据库服务器的磁盘进行了IOPS值的限制，限制值为5000。 
  1、为何要限制IOPS？ 
  由于根据实际项目经验，不少项目的没有特别强悍的数据库服务器，特别是磁盘IOPS，每每会成为系统瓶颈所在，本次测试经过限制IOPS值，也同步验证下F9框架在特定IOPS极限值下是否能够知足性能需求。 
  2、为何限制在5000？ 
  5000这个数值，也是根据性能调优人员经验肯定。可认为，数据库服务器磁盘IOPS 5000是基本的硬件指标要求，若是低于此值，能够认为硬件条件不达标，难以知足大型项目高并发要求，须要调整数据库服务器资源投入。 
  另外，许多项目使用虚拟机做为数据库服务器，且使用共享磁盘，IOPS能力也被分占，每每达不到5000 IOPS的要求，因此在大型项目或对系统性能有必定要求的项目中，不推荐使用虚拟机做为数据库服务器。

4.二、通俗化的性能基线指标

  因为目前的性能需求每每都是并发+响应时间这样的描述，并不能对应的了QPS值，没法指导计算资源评估，为了将性能基线通俗化，须要进行一下换算。考虑到事务复杂度不一，为了便于换算，统一预估单事务平均包含10个请求，单事务响应时间为3秒。基于单机器4核8G，QPS值为650~1000之间，依照换算公式“并发=QPS/单事务请求数*事务响应时间”，支撑并发量为195~300之间。故通俗化的基线指标为，单台4核8Gweb服务器，支持用户并发195~300间。按此，一个须要知足1000并发量要求的系统，大体须要4台4核8Gweb服务器。