loadrunner 关于计算及瓶颈识别（五）

         通过吞吐量，并发数和响应时间，我们可以大概了解一个系统的性能。当并发数增大时，吞吐量会增大，响应时间有所增加。但并发数继续增加时，响应时间增大的幅度变大，而吞吐量逐渐平缓稳定。当并发数继续增大，响应时间会明显快速增大，而吞吐量可能因为服务器压力过大，反而出现下降。所以一定要结合起来一起看。

一、并发用户数

        在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。当然，在性能测试上，任何公式都不是严谨的，最重要的是对系统做出有效正确的分析

        并发用户数量的统计的方法目前还没有准确的公式，因为不同系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式为：使用系统用户数量*(5%~20%)。对于这个公式是没有必要拘泥于计算的结果，因为为了保证系统的扩展空间，测试时的并发用户数量要稍微大一些，除非是要测试系统能承载的最大并发用户数量。举例说明：如果一个OA系统的期望用户为1000个，只要测试出系统能支持200个并发用户就可以了。

1、经典公式

（1）  平均的并发用户数： C = nL/T      

                其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

            （ps: n的单位为day, L和T的单位为h）

（2）并发用户数峰值 C‘ = C + 3*根号C

            举例1.  假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。

           →  C = nL/T =  400*4 / 8 = 200

           →  C‘ =  C + 3*根号C = 200 + 3* 根号200 = 243

             举例2. 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。 则一个月最后一周的平均并发用户数为（朝九晚五）：

           → C = nL/T  = （170000 * 50% *70% / 5） *（5/60）/  8 = 124

              举例3 .早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。

            → C = nL/T  =  1000*(5/60)/0.5 = 166.7

2、通用公式（对绝大多数场景）

            （1）  平均的并发用户数 =  （用户总量/统计时间）*影响因子                     （一般为3，可以根据实际情况增大）

              举例4 .每天电梯乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，

                            则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S

                            考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，

                            假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12

3、根据PV估算

                  （1）  平均的并发用户数 = （PV/统计时间）*影响因子  --------和上面类似

                        举例5.  比如一个网站，每天的PV（页面浏览数page views）大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS(每秒处理的消息数 Transaction Per Second )为：

                          TPS =  1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：

                           C =  246.92*3=740

4、根据TPS估计

         C = (Think time + 1)*TPS

5、根据系统用户数计算

           C = 系统最大在线用户数的8%到12% , 举例1：C  = 3000*0.08 = 240  (与公式相差40)

备注：本人目前在网上只找到了这5种，计算并发用户数的方法，其他计算方法，欢迎大家留言补充

二、吞吐量

吞吐量计算为：F = Vu * R / T    （个/s）

F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间

三、响应时间

对请求作出响应所需要的时间

四、举例 :  性能测试流程

制定性能测试目标-->选择性能测试工具-->设计性能测试-->执行性能测试脚本-->监控分析系统-->性能调优

1、目标：

如，系统需满足系统用户数220w（目标使用用户/注册用户）、在线用户50w, 并发用户1w（在同一时刻与服务器进行了交互的在线用户数量）的情况下，发帖响应时间不超过2秒，系统资源使用率不超过30%。

经典公式：C = nL/T  =  50w* (5/60) / 8 =  0.52w

根据系统用户数计算： = 50 w* 8% =  4   -_-||

2、选择性能测试工具：

可选择LR、Locust、jmeter等主流测试工具，这篇文章主要介绍LR相关。

3、性能测试准备：

测试脚本开发、负载的生成规则及监控方式、测试环境的搭建。

4、负载过程、负载后对数据进行分析，这个分析需要众多专家共同协作，找出数据背后的问题，确定性能瓶颈。

5、确定瓶颈后，进行软硬件调优，调优完成重复之前的步骤。

        需要与数据库交互的压测，事务pass不代表实际操作一定成功，首先确保脚本中的检查点要写正确，其次务必查询一下数据库是否有相应操作。

        场景测试的前10分钟，随时关注一下TPS、响应时间，若TPS过低或响应时间太慢，当机立断停止场景运行，找一下运行慢的原因，若不是脚本设置原因，找一下开发同学反馈问题，待开发调优后再压测，避免浪费时间。

        若无以上问题，场景测试的前1小时，关注一下曲线波动情况，若有明显下降或上下波动很明显，请联系开发同学查原因。

        若1小时已通过，可以连续跑稳定性测试，12小时或更长，当然中间有时间也要关注一下曲线图是否有异常。

五、LR如何识别系统瓶颈

1、Average Transaciton Response Time（事务平均响应时间）

        通过它可以分析场景运行期间应用系统的性能走向。随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

2、Hits per Second（每秒点击次数）

        是Vuser每秒向web服务器提交的HTTP请求数，查看曲线情况可以判断被测系统是否稳定。曲线呈下降趋势表明web服务器的响应速度在变慢，其原因可能是服务器瓶颈问题，也有可能是Vuser数量减少，访问服务器的HTTP请求减少。

3、Transactions per Second（每秒通过事务数）

        当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

4、吞吐量（Throughput） 

            表示服务器在任意时间的吞吐能力，即任意时间服务器发送给Vusers的流量。其是度量服务器性能的重要指标，度量单位是字节，另外也有兆字节。 

5、运行Vuser—吞吐量合并关联图

并发用户数和吞吐量瓶颈之间存在一定的关联，（在网络和服务器正常的情况下，随着并发用户数增加，网络吞吐量也会增加。）因此可以通过不断的增加并发用户书和吞吐量观察系统的性能瓶颈。然后从网络、数据库、应用服务器和代码本身4个环节确定系统的性能瓶颈。

6、查看事务是否全部通过    

        如果有事务失败，则需要深入分析原因。很多时候，事务不能正常执行意味着系统出现了瓶颈，如果事务失败过多，则应该降低压力继续进行测试

7、运行Vuser—平均事务响应时间合并关联图

        通过该合并图可以分析随着用户数量的变化，各个事务平均响应时间的变化，从而可以得出各个事物在制定时间内最大的并发用户数。

8、Hits per Second—Throughput 合并关联图

        在比较吞吐量和每秒的点击率中我们可以获得服务器在执行过程中的情况。如果服务器如和预期的一样在执行，那么吞吐量会随着它每秒的点击量增加而增加。这是期望实现的情况，因为点击增加一次就会需要服务器发送更多的信息给用户。如果电机的次数增加而吞吐量恒定或减少以及在固定范围内壁咚，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务反应时间的增加。

9、HTTP  Responses per Second（每秒HTTP响应数）

        “每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态码的数量，还能返回各类状态码的信息，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。常见http状态返回代码如下：

200（成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

201（以创建）请求成功，并且服务器创建了新的资源。

202（已接受）服务器已接受请求，但尚未处理。

203（非授权信息）服务器已成功处理了请求，但返回的信息可能来自另一来源。

204（无内容）服务器已成功处理了请求，但没有返回任何内容。

205（重置内容）服务器已成功处理了请求，但没有返回任何内容。要求用户清除表单内容，输入新的内容

206（部分内容）服务器成功处理了部分请求。

301（永久重定向）请求的网页已永久移动到新位置。服务器返回此响应（对Get或Head请求的响应）时。会自动将请求者转到新位置。

404（请求的网页未找到）服务器找不到请求的网页。例如，对于服务器尚不存在的网页经常会返回此代码.

500（服务器内部错误）服务器遇到错误，无法完成请求，一般是由于页面代码加载出错造成。