按照你的公式：170000*0.8/(3600*0.2)=188.8888889 不知道你怎么算出来是 16 和 23？

另外压测结果中产生的 tps ，除了和并发数有关，还和接口的实际处理时间有关。处理时间越短，平均每秒能处理的事物数量就越高，tps 就越大；反而如果处理时间很长，平均每秒的处理事物就越少，tps 也越少。

算出来的 TPS 分别是 16 和 23 ... 给一个接口跑了几遍 20 人的并发，TPS 都是 500+，不知道这又是为什么，查了这么多？

首先，TPS 有分目标值和实际值，目标值是按照你业务评估最低要达到的值，实际值是你实际压测得到的值。性能测试就是要让 TPS 的实际值大于等于目标值，响应时间的实际值小于等于目标值，才能算通过。

所以你目标值是 16 或者 23，和实际值达到 500+，是没有问题的呀，说明你的系统单个接口的性能可以满足要求。但是否可以通过，你还得测试下多接口调用的混合场景才能确认。

怎么决定开始人数和每阶段增加人数以及每阶段持续时间？有没有大佬能给个通俗易懂的讲解啊？感激不尽！

之前看了极客时间高楼老师的课，他的观点是：这个不重要，选一个能看出阶梯性的值即可，比如开始时 10 人，后续每 1 分钟增加 10 人。观察 TPS 是否也是按一样的阶梯上升，大概到多少时 TPS 不再上升而是响应时间增加（说明到了性能瓶颈，压力再增加，只会继续增加响应时间影响用户体验了）

至于并发线程数和用户数的关系，其实可以说是没有很明确的关系，毕竟你 100 人同时在线，根据业务情况，有可能每个用户都很活跃达到每秒 100 TPS（比如秒杀），也可能其实操作不频繁每秒 5 TPS（比如发信息，打字要花不少时间）。以前性能测试的书也会告诉你，最高峰 100 人同时在线，对应压测工具并发用户数不一定是 100 人，因为还有并发度或者思考时间什么的。而高楼老师进一步简化为了：压测给了多大压力不那么重要，重要的是找到系统性能瓶颈在哪里（TPS 到了某个值，再加并发线程数都不会上升，就表示达到瓶颈了），并根据达到瓶颈时的 TPS 是否可以满足业务需要来判定是否通过。

我个人还是挺认可高楼老师的观点的，毕竟确实没有非常有科学依据的公式去倒推各个客户端合并给到服务端的压力多大，那些传统的二八原则，拉一下实际线上监控数据看看，其实很可能真的不是这个比例。至于目标 TPS 要达到多少，可以结合实际场景的接口调用逻辑 + 用户操作场景，设定初始值，然后和产品、开发沟通，得到一个相对靠谱的值。最靠谱是直接拉线上监控数据，但新系统新业务是没线上数据的，所以主要靠前面说的去推断。

1、用线上流量统计来计算线上真实压力

根据日 UV 和日 PV 来推导线上真实并发压力，可能会出现严重的性能评估偏差。

因为服务端的并发压力，跟业务本身的特点强相关。

举个例子：秒杀系统，1 秒钟放入 100 万用户，和 1 分钟放入 100 万用户，是截然不同的两种并发压力。

所以，不建议根据 UV 或 PV 来分析并发压力。

建议：根据服务端接口的流量统计来评估当前线上真实 TPS 压力
如果性能目标是满足接下来半年到一年的业务需求，再根据业务增长速度，计算需要的性能冗余。

性能目标评估例子： 比如过去一年，用户数有 100 万，历史峰值 QPS 是 1000。如果接下来一年，我们的目标是用户增加到 500 万，那么线上实际需要的 QPS 目标就是 5000，考虑到业务增长不可预测性（比如超过 500 万）、服务器和开发资源的提前准备、业务的不稳定等，一般准备 3 倍性能冗余，即目标可以定为 5000*3 = 1.5 万，这样满足 1.5 万 TPS 要求的服务，在未来一年内，在软件层面，出现严重性能故障的情况，将比较小。

2、用什么压力模型来测试

如果是一个新系统，建议压力模型顺序：
（1）评估系统压力、拐点、不同压力下表现：用 负载测试（阶梯式加压），建议每个阶段增加的并发，能明显改变性能曲线。比如每分钟增加 100 用户，发现性能直接打满了，那就用二分法，下次每分钟增加 50 用户再试试。
（2）评估系统某个压力下，满足某个业务场景的性能表现：用 压力测试，比如一个持续半小时的活动，那就用目标压力，持续测试 1 小时，观察这期间系统表现。
（3）评估系统稳定性：用稳定性测试，目标压力下，持续运行 7*24 小时，观察系统稳定性，以及是否有内存泄漏。

以上三种压力模型，基本可以满足绝大部分性能需求。

3、建议：先熟悉服务端性能的基本知识

服务端性能的执行，其实大家学习一下基本都能搞定。
但是如果保障自己服务端测试的质量，即能准确做出满足性能目标的性能测试，需要好好考虑和熟悉性能测试的基本概念。
性能概念不清楚的，建议阅读：服务端性能测试 - 入门指南
性能测试工具学习的，建议阅读：服务端性能测试 - 工具篇 (Jmeter)

性能测试工具大同小异，一通百通。

让压力阶梯型上升并不通用,像考试系统这种业务,考试一开始上来就是全量用户.

16 和 23 是分别按照公式的分母再乘以 8 和 24 算出来的。你说的接口处理时间这个确实需要关注，毕竟如果单接口的话，在极短的时间内就处理了，这样跑出来的结果应该不太具有参考性。

感谢大佬，实际值与目标值我明白了。项目是一个在线购物网站，我现在应该构建一些场景的测试用例，比如注册 + 登录、切换查询商品、添加商品到购物车，这样的接口组合，再去跑，对吧？还有就是像这种购物网站的话，如果按照我上面的公式来说，是应该采取分母乘以 8 还是 24 呢？项目是国外的项目，还需要考虑黑色星期五和圣诞的情况。（虽然楼里有大佬不建议根据 UV 和 PV 分析，只是目前只有这 2 个数据，因此我的想法是先根据公式给出大概的标准范围，之后可以根据客户提供的更多信息再进一步完善优化）

得明确目标，是容量规划还是性能测试，不同的目标，做不同的事，如容量规划，让开发和产品根据场景定义目标 TPS，而这个目标 TPS，是否能够通过加机器方式提升 (即扩容线性增加)。如性能测试，更多是寻找性能瓶颈。TPS 固然重要，但其目标是发现系统的瓶颈。

因为是新的系统，还没有部署生产。当前的目的是通过压力测试来寻找一些可能遇到的问题，来决定部署生产的配置。

是的，这个和业务场景会比较强相关，不同业务场景要用不同的压力策略模拟。

公式： PV*80% / 3600*20% =TPS 的值 3600 代表 1 个小时 3600 秒】

看了下，你这个公式好奇怪，为啥直接用一天的 PV 去除以一个小时的 20% 时间？一天 80% 的接口访问量都在 12 分钟内灌进来？这个比例有点夸张了吧。

日 PV 是一天的量，性能测试里常说的二八原则一般是指 24 小时里，80% 的访问集中在 20% 的高峰期，按照这个去推算，峰值 TPS 应该是 日 PV*80% / (24 小时 *3600 秒 *20%) ，按你这里 17W PV ，算出来应该是 7.8 左右 ？

PS：TPS 是接口维度的数据，PV 是用户维度的数据，用户和接口是一对多的映射关系，而且随着活跃度差异、接口逻辑差异，这个一对多比例也会产生很大差异。所以你直接拿 PV 来算，算出来最多就是一个当天首次访问获取 token 这个接口的 TPS，并不能代表整个系统各个接口的 TPS 要求哦（比如平均一个用户会查看 10 个商品，那商品查看接口的累计访问量应该是 PV 的 10 倍。个人了解电商购物类网站，商品查看一般调用频率也是最高的，所以也是最需要做缓存、性能优化的地方）。

如楼上所说，不结合业务场景和逻辑，单靠一个 UV/PV ，实际是算不出系统各个接口的 TPS 目标值数据的，这样得到的数据大部分情况下会比实际值小，就算达到了也不代表能满足实际业务需要（比如按照前面的假设，商商品查看接口 TPS 目标不应该只有 7.8）。建议先理清楚核心业务流程背后接口调用时序，然后顺着业务逻辑来评估几个调用量比较大的接口的目标 TPS 吧。

对的，我在帖中就是质疑了这个公式的错误，只是另外的资料中有的是 3600*20% 再乘以 8，有的是乘以 24，我不知道该采取哪种，现在来看，对于我这个项目来说乘以 24 的是对的。不过我昨天是在公司算 7.8 的，回家发帖的时候记错了记成了 16。
看了大家的回答，我现在的理解是，如果按照公式来算，出来的结果是 7.8，这个 7.8 的 TPS 可以大致理解为 24 小时的平均事务处理，而对于具体的项目来说，有一些场景是需要的 TPS 是远超过这个平均值的，就需要针对不同的业务上的场景设计不同的用例，来监测这些场景下的 TPS 值，最终通过分析这些值来确定整个系统的性能的指标以及需要的服务器的大致配置，可以这样理解吗？

大部分理解和我理解是一致的，有一小部分不大一样

就需要针对不同的业务上的场景设计不同的用例，来监测这些场景下的 TPS 值，最终通过分析这些值来确定整个系统的性能的指标以及需要的服务器的大致配置

根据不同场景设计不同用例这个是对的，但基于这些场景下的 TPS 值分析确定系统性能指标这个不大对。

性能指标应该是基于真实业务场景分析来制定的，而不应该是基于压测结果制定。比如同样 TPS 数据，线上的 TPS 数据，代表真实业务情况，所以可以作为场景分析的参考数据，而你自行压测得到的 TPS，只是你自己模拟得出的数据，可以用于验证性能是否达标，但不能用于作为场景分析的参考数据。实在没有线上数据可供参考，那和产品开发一起讨论，一起推敲出一个值也行。

感觉你目前在概念层面上有些理解不大对，需要有比较完善的文章或者示例，而不仅仅是我在这里只言片语的答复。建议可以看看楼上贴的 服务端性能测试 - 入门指南 ，或者去极客时间看看高楼老师的课程。目前是支持任选几讲免费试读的，你可以选关于基于业务场景制定性能指标的章节看下。

也许在你这个场景下，实际对性能要求并不那么高（PV 17W，对一个线上系统来说应该不算高负荷），但这些理念尽量入门时要了解好，避免后面走偏。性能测试的场景和目标指标制定是非常关键的，没做好，很可能会引起你性能测试结论是通过，但线上真正达到预计范围内的高峰期时系统却扛不住挂掉，那你这个性能测试基本就是白做了。我们之前就遇到过，花了快一个月专项做性能测试，结果上线后流量来了，就各种扛不住（我们当时是监管要求必须切新系统，所以不可能小流量慢慢上，一上来就是全量），后面研发就各种吐槽当时花那么多时间做的性能测试和调优，一点效果没有。

好的，感谢！