阿里云-性能测试服务实践指南-D.docx

性能测试Lite实践指南Lite实践指南访问Lite控制台一、 概述大家做性能测试很大程序是想评估被测系统在一定负载压力下性能表现如何，而在测试过程中，很多人只是用 并发用户数来衡量系统的性能，没有考虑其他前提条件，比如响应时间；觉得系统能支撑的并发用户数越多，系统的性能就越好；对TPS也不是非常理解，也根本不知道它们之间的关系。为了更好的选择合适的虚拟用 户数进行压测，需正确理解虚拟用户数、TPS、响应时间之间的关系。二、 术语定义虚拟用户：性能测试中通过线程或进程执行脚本来模拟典型用户访问系统行为的用户。TPS: 每秒处理事务数, 是衡量系统性能的一个非常重要的指标。在线用户（或活跃用户）：一个时间段内，与服务器保持交互的用户，也称为活跃用户。需与论坛或者QQ上常 见的在线人数定义区分，该类系统的在线用户不一定是活跃用户，在线只是一种状态。但在业务类系统中，一般只考虑活跃用户，可认为与在线用户通用。并发用户：表示同一时间与服务器保持交互的用户。响应时间：简称RT,指的是业务请求从客户端发起到客户端接收服务器端响应请求完成的时间。思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。三、 在线用户数和并发用户数的区别下图中红色表示访问首页操作、黄色表示访问投票页面操作、橄榄色表提票提交操作、绿色表色投票统计结果 查看操作、蓝色表示等待行为。等待行为是什么呢？比如用户在页面填写内容、浏览页面信息、浏览统计 结果数据，这些用户在客户端行为与服务器无任何交互，对服务器来说是没有负载压力的。我们可以从图中看出25个用户在线访问投票系统，每个用户操作流程是:1.访问首页,2.浏览首页,3.访问投票页面,4.填写投票表单内容,5.投票提交,6.投票统计结果查看访问,7.浏览统计结果。其中1,3,5,6操作会与服务器进行交 互，对服务器形成负载压力，而2,4,7操作是用户在客户端的行为，并没有于服务器进行交互，对服务器没有任 何压力。从时间视角1来说，当前活跃用户数（在线用户）是25,并发用户数只有7个，为什么呢？因为从当前视角来看只 有7个用户在同时与服务器进行交互，对服务器形成了负载压力，而其他18个用户都在等待行为状态。那么从视角2来看，活跃用户数（在线用户）仍然是25，并发用户数是多少呢？答案是6个。所以我们在虚拟用户在模拟用户行为的时候，如果虚拟用户中包含等待行为的话，那么虚拟用户数=在线用户 数；不包含等待行为的话虚拟用户数=并发用户数。四、 虚拟用户数、响应时间、TPS之间的关系在术语中解释了TPS是每秒事务数，但是事务是要靠虚拟用户做出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快 慢。由此我们可以一个公式： TPS=虚拟用户数/响应时间通常针对服务器端的性能评估，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须 要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数 来衡量系统的性能没太大的意义。五、 施压策略建议通过很多性能测试案例，发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用 户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目，基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。在做负载测试的时候，一般都是按照梯度施压的方式去增加虚拟用户数，而不是在没有预估的情况下，一次加 几万个用户，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义。六、 总结系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通 过加思考时间设置）。系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。建议性能测试的时候，不要设置过长的思考时间或不设思考时间，以最坏的情况下对服务器施压。一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压 力测试，1000个用户并发就足够了访问Lite控制台访问Lite控制台性能测试结果解读和分析是一个较