Question

loadrunner关于吞吐量的性能测试结果分析

我测试的某网站的登录，在并发达到10个的时候，吞吐量就上不去了，看一下下载网速达到了6.9M，也就是说，在增加负载影响响应时间的很可能就是网速了，请问10个用户就达到这么大是不是不正常，一般会是什么地方出了问题

Answer 1

　第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。
　　例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。
　　第二步：测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大的影响。因此，当测试出现异常时，我们要对场景设置进行分析。
　　一些新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户，如果客户端来不及处理，就 会有很多虚拟用户因不能初始化而失败。失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。正确的做法是增加更多的 Generator或逐步加压，使测试场景运行起来。
　　第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统 的性能问题，应该进一步调整场景(比如增大压力)进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上，分析能够反映性 能问题的测试结果才是性能分析阶段的主要工作。
　　测试结果直接暴露系统存在性能问题的情形很多，例如在测试过程中一些用户事务响应时间过长、系统支持的最大并发用户数过低、系统的应用服务器CPU利用率 过高或内存不足等。对这类测试结果，性能测试人员需要借助Analysis对其进行深入分析，以发现一些潜在的性能问题。

Answer 2

看你的这个图，vuser数量在大致8min至12min内维持着最大数量，
但是你看每秒点击数，在很早的时候，5min不到，就已经基本稳定了，这似乎说明vuser已经被阻塞在了服务器的队列里面，得不到及时处理，服务器能处理的请求已经达到了极限，
一旦这个指标的极限早于vuser数量的极限出现，就要怀疑服务器端的IIS是否做了保护，而且保护得太紧了，服务器也许还有更大的处理能力，但被限制了；
所以响应时间与vuser的吻合就很好解释了，但是也看不出来什么东西了，
同理，吞吐量也因为这个原因，看不出来什么东西，应该不是像你描述的“上不去了”，
建议你看一下服务器端的配置，把那个保护放开，再把压力压上去看看