如何应用性能测试常用计算公式
1．问题提出
性能测试中有很多非常重要的概念，如吞吐量、最大并发用户数、最大在线用户数等。有很多读者也非常关心，如何针对自身的系统确定当前系统，在什么情况下就可以满足系统吞吐量、并发用户数等指标要求呢？
2．问题解答
（1）吞吐量计算公式。
吞吐量（Throughput）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。通常情况下，吞吐量用"请求数/s"或者"页面数/s"来衡量。从业务角度来看，吞吐量也可以用"业务数/h"、"业务数/天"、"访问人数/天"、"页面访问量/天"来衡量。从网络角度来看，还可以用"字节数/h"、"字节数/天"等来衡量网络的流量。
吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标，一般吞吐量越大，系统单位时间内处理的数据越多，系统的负载能力也越强。
吞吐量是衡量服务器承受能力的重要指标。在容量测试中，吞吐量是一个重点关注的指标，因为它能够说明系统的负载能力。而且，在性能调试过程中，吞吐量也具有非常重要的价值，例如，Empirix公司在报告中声称，在他们所发现的性能问题中，有80%是因为吞吐的限制而引起性能问题。
显而易见，吞吐量指标在性能测试中占有着重要地位。那么吞吐量会受到哪些因素影响，该指标和虚拟用户数、用户请求数等指标有何关系呢？吞吐量和很多因素有关，如服务器的硬件配置，网络的拓扑结构，网络传输介质，软件的技术架构等。此外，吞吐量和并发用户数之间存在一定的联系。通常在没有遇到性能瓶颈的时候，吞吐量可以采用下面的公式计算：
这里，F表示吞吐量； 表示并发虚拟用户个数（Concurrency Virtual User，并发虚拟用户），R表示每个VU发出的请求数量，T表示性能测试所用的时间。但如果遇到了性能瓶颈，此时吞吐量和VU数量之间就不再符合给出公式的关系。
（2）并发数量计算公式。
关于并发（Concurrency），最简单的描述就是指多个同时发生的业务操作。例如，100个用户同时单击登录页面的"登录"按钮操作。通常，应用系统会随着用户同时应用某个具体的模块，而导致资源的争用问题，例如，50个用户同时执行统计分析的操作，由于统计业务涉及很多数据提取以及科学计算问题，所以这个时候很有可能内存和CPU会出现瓶颈。并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式。
有很多用户在进行性能测试过程中，对"系统用户数"、"在线用户数"、"并发用户数"的概念不是很清楚，这里我们举一个例子来对这几个概念进行说明。假设有一个综合性的网站，用户只有注册后登录系统才能够享有，新闻、论坛、博客、免费信箱等服务内容。通过数据库统计可以知道，系统的用户数量为4000人，4000即为"系统用户数"。通过操作日志我们可以知道，系统最高峰时有500个用户同时在线，关于在线用户有很多第三方提供插件可以进行统计，这里以http://www.51.la为例，这里"在线用户数"即为500。这500个用户的需求肯定是不尽相同的，有的人喜欢看新闻、有的人喜欢写博客、收发邮件等。这里假设这500个用户中有70%在论坛看邮件、帖子、新闻以及他人博客的文章（有一点需要提醒大家的是，"看"这个操作是不会对服务器端造成压力的）；有10%在写邮件和发布帖子（用户仅在发送或者提交写的邮件或者发布新贴的时候，才会对系统服务器端造成压力）；有10%的用户什么都没有做；有10%的用户不停地从一个页面跳到另一个页面。在这种场景下，通常我们说有10%的用户真正对服务器构成了压力（即10%不停地在网页间跳转的用户），极端情况下可以把写邮件和发布帖子的另外10%的用户加上（此时假设这些用户不间断的发送邮件或发布帖子），也就是说此时有20%的用户对服务器造成压力。从上面的例子可以看出，服务器承受的压力不仅取决于业务并发用户数，还取决于用户的业务场景。
那么如何获得在性能测试过程中大家都很关心的并发用户数的数值呢？这里我们给出《软件性能测试过程详解与案例剖析》一书中的一些用于估算并发用户数的公式。
在公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算公式，其中，C 指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
下面给出一个实例来讲述公式的应用。假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出系统平均时间为4h，在一天的时间内，用户只在8小时内使用该系统。则根据公式（1）和公式（2），可以得到 ， 。
除了上述方法以外，还有一种应用更为广泛的估算方法，当然这种方法的精度较差，这种公式的计算是由平时经验的积累而得到，相应经验公式为： （公式（3））和 （公式（4））。通常，用访问系统用户最大数量的10%作为平均的并发用户数，并发用户数的最大数量可以通过在并发数上乘以一个调整因子r得到，r的取值在不同的行业可能会有所不同，通常r的取值为2～3。系统用户最大数量可以通过系统操作日志或者系统全局变量分析得到，在没有系统日志等手段得到时，也可以根据同类型的网站分析或者估算得到（当然这种方法存在着一定的偏差，读者应该酌情选择），现在有很多网站提供非常好的网站访问量统计，如http://www.51.la（我要啦免费统计网站），用户可以申请一个账户，而后把该网站提供的代码嵌入网站，就可以通过访问"我要啦免费统计网站"来查看每天的访问量、每月的访问量等信息。r（调整因子）的确定不是一朝一夕就可以得到，通常需要根据多次性能测试的数据，才能够确定比较准确的取值。所以，大家在平时进行并发测试过程中，一定要注意数据的积累，针对本行业的特点，确定一个比较合理的r值。如果能知道平均每个用户发出的请求数量（假设为 ），则系统接受的总的请求数量就可以通过 估算出来，这个值也就是我们平时所说的吞吐量。
（3）思考时间计算公式。
思考时间（Think Time）是在录制脚本过程中，每个请求之间的时间间隔，也就是操作过程中停顿的时间。在实际应用系统时，不会一个接一个地不停的发送请求，通常在发出一个请求以后，都会停顿一定的时间，来发送下一个请求。
为了真实的描述用户操作的实际场景，在录制脚本的过程中，通常，LoadRunner也会录制这些思考时间，在脚本中lr_think_time()函数就是实现前面所说的思考时间，它实现了在两个请求之间的停顿。
在实际性能测试过程中，作为一名性能测试人员，可能非常关心怎样设置思考时间才能够跟实际情况最合理。其实，思考时间与迭代次数、并发用户数以及吞吐量存在一定的关系。
如 （公式（5））说明吞吐量是VU数量 、每个用户发出请求数 和时间 的函数，而其中的 又可以用时间 和用户的思考时间 来计算得出， （公式（6）），用公式（5）和公式（6）进行化简运算可得，吞吐量与 成正比，而与 成反比。
那么，究竟怎样选择合适的思考时间呢？下面给出一个计算思考时间的一般步骤。
① 计算出系统的并发用户数。
② 统计出系统平均的吞吐量。
③ 统计出平均每个用户发出的请求数量。
④ 根据公式（6）计算出思考时间。
为了使性能测试的场景更加符合真实的情况，可以考虑在公式（6）的基础上再乘以一个比例因子或者指定一个动态随机变化的范围来仿真实际情况。
经常会看到有很多做性能测试对是否引入思考时间在网络上的争论，在这里笔者认为思考时间是为了模拟真实的操作而应运而生，所以如果您要模拟真实场景的性能测试建议还是应用思考时间。但是，如果要考察一个系统能够处理的压力-极限处理能力，则可以将思考时间删除或者注释掉，从而起到最大限度的发送请求，考察系统极限处理能力的目的。
via:http://book.51cto.com/art/201311/419808.htm
注：转载需注明出处及作者。
