响应时间小为什么事务数反而少？

navysz

对比两个服务器，其他环境完全相同，包括数据库，测试脚本，测试场景，测试时间，唯一不同的是两个应用服务器，这两个应用服务器的端口都一样，测试哪个启动哪个，另一个停止。 64

结果很令人费解，
应用服务器A的平均响应时间为 12.216 秒，每秒事务数为 64.371
应用服务器B的平均响应时间为 1.611 秒，每秒事务数为 59.735
到底哪个服务器的性能好？为什么响应时间小的反而总事务数和每秒事务数都少？见图：

应用服务器A：


应用服务器B：

大漠行者

理论上，响应时间短，对应的吞吐量就大。在这个用例中，依据现有的数据，结果是合理的。 或许在第二个测试中有失败的事物，尽管没有在结果中体现出来。 想知道你应用场景中的think time如何设置的？

navysz

当然每个系统都可能有瓶颈，不过对于loadrunner来讲，所有系统对它来说都是黑盒，系统内部如何实现以及有没有瓶颈，它并不关心，也没理由关心，它只是向系统发出请求，接收响应，统计时间及事务完成数，按常理说，事务数应该和请求的响应时间成反比的，但实际中违反的情况比比皆是，以至于我很疑惑，评价一个系统的性能好坏，到底是用事务数合理些，还是响应时间？

我倾向于用事务数（或吞吐量），因为在我看不出事务数和响应时间的关系的情况下，起码，事务数表示系统能完成这么多事。否则，你响应时间再短，但干的活少，也是白搭。

msnshow

按理讲，相同条件下，应该是响应时间短的响应数会高

估计还是某些资源有瓶颈

msnshow

这个结果不是太正常

zhangting02

这个问题我也想知道