Locust 理解错了, 重新捋了下, 它的 TPS 是按照最近 2s 内的统计结果计算的.
不过这仍然没解决问题 1 和 2 的疑问 ......

感觉问的不像是测试，而是性能工具的研发了，至少我个人没看过 locust 的源码，满足于 Jmeter
TPS 里的 S 就是秒，结合上下文，每秒的 TPS 这一说法不就有点奇怪吗。
每一秒完成的事务数是 TPS，所以只要定好时间范围，计算好事务数再除以时间范围就是最后的结果。
如果目的是画图，想清楚横轴怎么设计就好了，应该没有哪个 TPS 示意图横轴刻度是 1 秒吧。
对于问题一，感觉没什么毛病，这请求是在第二个 10 秒内被完成的，当然不能统计到第一个 10 秒里去，至于它是什么时候发起的并不重要。

感谢回答
是的,因为业务的关系,,有个需求是需要设计个分布式的发压能力且频率可定制 (类似回滚场景). 但是对性能这块的概念没整明白关于数据的统计存在这些疑惑.
TPS 的字面意思每秒完成的事务总数. 我大概明白这个. 但是像对于问题 1, APi 在服务器端被处理了 15s(忽略等待时间), 那么每秒占比 1/15, 第一个 10 秒内它占了处理过程的 10/15 的时间, 按照这个理解的话, TPS 解释中每秒完成的事务总数, 重点是"完成"态么？并不需要对前面消耗的负载时间做统计的意思吗.

问题 1 和问题 2，归根结底还是 TPS 的统计问题。即处理事务横跨多秒时，计数应该算到起始时间段还是完成时间段。

个人理解， TPS 一般是用完成时间来计算的，因为这样计算，性能消耗成本最低（只要在完成时加一个记录即可）。如果按开始时间，甚至按照持续时间拆分，那么每个请求还得额外消耗资源去存储和计算这些。我觉得，对性能工具来说，发起大压力才是它的最根本的职责。统计数据这些说实话，只是附属功能，交给其他外部监控程序做都完全没问题（nginx 日志就可以反映每秒请求数量和每个请求的处理耗时了），没必要为了统计准确那么一点点，增加那么多系统负载，进而导致无法发起更大的压力。

至于消耗的时间统计，这个是用响应时间这个指标来统计的，不是用 TPS 。一般看性能测试结果，响应时间和 TPS 都得看。TPS 反映的是系统性能是否已到达瓶颈（即在当前配置下都已经没法再快了），响应时间反映的是达到瓶颈后整体处理时间延长的情况（即给到每个用户体感，会慢多少）。

那就明白了, 其实并不是说请求起始时间到结束时间的横跨时间内不需要计算 TPS, 而是从性价比考虑, 请求完成时间来代表的话已经能够基本满足 TPS 的波动图所反映的服务器处理能力, 它结合响应时间图, 还有资源消耗的监控来整体评估判断.

非常感谢解答......

不客气。

这个也只是我个人观点，实际性能工具作者自己的思考，可能还得问作者本人才能知道了。我只知道在 Jmeter 或者 nginx 里面，每个请求结束后（包括超时或异常引起的结束），都会记录一条日志，带有响应码、响应时间、记录时时间戳等信息。所以基于这类工具做 TPS 统计，最方便的方式就是基于这个日志来统计了。

再请教下案例问题:
有个场景, 昨天碰到的, 它的 API 响应时间波动较大, 受并行和使用的数据影响波动很大. 举个例子, 我对这个 APi 设置了场景为第一分钟启动 10 个并发, 然后往后每分钟增加 2 个并发.(起始是 10 个客户, 每分钟递增 2 客户), 然后每个线程的操作都是 While True 的方式去请求这个 API.(可以理解为第一分钟有 10 个客户在持续操作, 第二分钟有 12 个客户在持续操作.往后类推).
测试结果中, API 的响应时间最低 3.2 秒, 最高 300 多秒. 1 个小时一共运行了 1900 多个数据.

问题: 对于这种测试, 它的 TPS 有参考意义吗？ 个人感觉好像没有多大意义, 因为大量的请求横跨的时间太长了, 中位数基本在 120 秒. 横跨这么久. 我按照 Locust 统计的方式去计算了每秒的 TPS 值 (以完成时间统计, 并且每秒值为之前 10s 的平均数). 结果 TPS 的记录在 0.3-1.7 之间高低波动并且没有看到起伏规律 (像无序,没看到有受并发增加而影响高/低). 反而其他监控比如 CPU 的资源监控, 响应时间监控. 都能够看到受到并行增加而对应升高, 直到升满. 趋势有规律

TPS 有意义，说明以目前的配置，你的系统实际能承受的性能水平就是这个水平了。没意义的是，你 TPS 已经没变化了，继续增大压力持续 1 小时没意义，因为你系统早就满负荷了，当响应时间增加到你觉得正常用户不可承受的水平时，就可以停止增大压力了。

至于响应时间增大，很正常。一般情况下，当全部处理线程都处于满负荷状态时（有监控工具可以看到这个信息），就已经达到最大 TPS 了。类比一下，类似常见的柜台处理业务。一共就 5 个柜台（类比 5 个工作线程），不足 5 个顾客时，还有余量，但超过 5 个顾客时，柜台已经达到最大处理速度了（以现有资源没有可提升的余量），第六个就开始排队了，继续加也只是队伍变长，柜台的处理能力还是不变的。要优化速度，要不增加柜台（增加线程数或者其他限制了速度的资源阈值），要不让每个柜台处理业务的速度加快（优化逻辑）。

这些性能测试的基本概念，建议可以看下极客时间高楼老师的性能测试课程，里面讲得比较清晰。

好的, 我找下课程阅读下, 感谢感谢......

另外, 关于你举的柜台 5 个顾客的例子, 我有个数据疑问, 如果在柜台处理业务过程中, 有个顾客存钱是刷卡, 处理很快, 有的顾客存在是点钞, 存钱相对慢, 有的顾客存在是称重硬币, 过程会相对更慢, 更有的顾客是人工点钞 (1 块 10 块一麻袋),速度最慢. 那么对于这种业务, 虽然 API 都是同一个处理存钱, 但是柜台 (服务器) 会因为顾客携带的钱类型 (API 的 body 数据) 而导致处理时间长短差别非常大. 这种情况下, 5 个客户同时刷卡和同时扛着麻袋存钱, 响应时间是非常差别大 (TPS 也跟着波动大小).
这种场景下, 对比 TPS 的参考性大么？

其实归结就是, 性能测试过程中, API 的数据因素干扰很大的时候, 如何处理呢? (数据是真实客户都有可能发生的数据,从客户的 Log 中抓来的, 并不是随便生成的)

这种场景下，就要考虑实际业务中，不同业务的实际请求比例（有条件可以线上直接通过日志分析等手段来做，未上线的话只能靠对业务逻辑的了解和与项目成员沟通推导了），然后在压测的时候，按照基本一致的比例来分配压力。这样测出来的 TPS 和响应时间，是具备参考意义。

好的. 有个轮廓概念了. 知道下一步怎么样做了.
ThankQ