下面给出一个实例来讲述公式的应用。假设有一个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）的基础上再乘以一个比例因子或者指定一个动态随机变化的范围来仿真实际情况。
　　经常会看到有很多做性能测试对是否引入思考时间在网络上的争论，在这里笔者认为思考时间是为了模拟真实的操作而应运而生，所以如果您要模拟真实场景的性能测试建议还是应用思考时间。但是，如果要考察一个系统能够处理的压力-极限处理能力，则可以将思考时间删除或者注释掉，从而起到大限度的发送请求，考察系统极限处理能力的目的。