- sky_you2021-06-03其实我很想问一下，假如没有日志，就是一个新系统，什么参照数据都没有。客户也无法给出性能目标。最多给你个单个功能，比如一个按钮不能超过三秒。然后我一天要处理多少个订单。 在这种情况下，性能测试是不是没有必要做了？ 老板会在做之前问，评估一下，我们能做出来多少并发的东西？我这个搞性能的是不是可以递交辞职报告了？？？
作者回复: 那只能凭感觉做了。为了生活，还是昧着良心随便给个结论吧。哈哈。
11 - 大白2021-04-08用户级操作的完整业务流时间（记得多采样一些数据，计算平均时间）。这个值也是从日志中取到； 1、这个平均业务流时间，才是最重要的核心机制，日志统计是大工程，难度较大 2、样本要尽量多，而且比例要到位，样本起码尽量要制定走完整个流程的用户比例和未走完流程的用例比例保持接近。这样才能满足真实用户的操作分布，因为每一个事务流程中的用户的思考时间由于业务的特殊性必然不一致。 3、按照这样理解，每个T的事务并发度其实都是不一样的，我感觉还是要做更细致的拆分。但是感觉这样就回到业务模型了啦。 4、 所以我思前想后在有日志的情况下，并发度的计算最大用处应该是最完容量测试后，最容量评估用的 5、如果是这样我是不是也可以业务模型的来反射出容量评估呢？ 例如我业务模型的通过日志采集完，1分钟内的 7个业务的比例和总的业务量/60s，就是平均TPS1，那么我照业务模型实际跑出来的TPS2，那么容量评估就是 TPS1时的在线用户*(TPS2/TPS1) 6、此时TPS2/TPS1其实也是并发度的一种计算，而不在是文中一个用户连续走完所有的业务时间，其中的6秒，按照文中的思路想好像是那么回事，但是仔细想好像过于极端了！因为用户真实场景是通过大量样本的统计的平均时间，而这个6S确实一个且单用户的样本数据 。 7、5中的问题点，就是TPS1的在线用户数的统计问题了，那么就统计出1分钟内的在线用户即可展开
作者回复: 1. 用日志系统可以统计。自己写代码也可以。一次性的工作，难度大也值得。 2. 嗯，这一点提的好。我应该加到正文中去。 3. 是的。本来也应该是把业务模型考虑进去的。 4. 对老板来说，是这样的。本来这个话题就是为了回答业务容量的问题。 5. 小伙子机灵呀。这是完全可以的。 6. 不管是大范围，还是小范围的计算，都可以，就看要回答的是什么问题。 7. 这个你可以试试去做一下。
3 - sky_you2021-06-03在线用户数。这个值可以从日志中取到； 在线用户数统计的时间段。这个值也可以从日志中取到； 用户级操作的完整业务流时间（记得多采样一些数据，计算平均时间）。这个值也是从日志中取到； 无停顿时间的完整业务流时间。这个值从压力工具中可以取到； 单用户完整业务流的请求数。这个值可以从日志中取到。 老师 全新的系统怎么办？
作者回复: 全新的系统在试运行阶段采集统计数据。 要不然就只能凭经验蒙了。
2 
X_man2021-09-17老师您好。看了你的文章产生几个疑问 1、线程数是不是就是虚拟用户数？ 2、并发用户数这个是等于线程数还是等于TPS数？我以前一直以为线程数是并发用户数相等，后面直到我看到高楼老师的这篇文章， 因为TPS来衡量服务器性能指标这个我是清楚的，但是平时测试的时候客户还有老板他们更关心的是并发用户，经常会问系统支持多少并发用户？我只能告诉他们支持多少TPS，因为他们的理解并发数就是线程数，虽然我不这么理解但是跟他们解释清楚很难 希望老师能帮我解惑作者回复: 1，显然不是。 2，在我的理念中并发是用tps承载的。
1- jy2021-09-07【抛砖引玉】 本文计算有个前提，就是在线用户也走了完整流程， 而实际场景中， 1、在线用户，不一定做了操作， 2、哪怕做了操作，也不一定是一个完整业务流程，可能只做了其中部分操作，比如查询商品。 所以，只计算在线用户的tps这样来获取并发度是不严谨的，而且要这种方式，考虑不同情况，感觉复杂度很高。 所以，我觉得更合理的办法还是统计时间段的在线用户（定时统计在线用户，比如在redis里面的token，根据采样数据在excel做透视图，根据趋势看平均大概是多少<性能实战里面老师说的tps约么是多少的方式>），并发度=无停顿时间tps/在线用户。
作者回复: 说得对。 这个计算前提我在文中描述过“不考虑业务模型”了。
1 
byyy2021-08-27多在线用户的 TPS 计算 1.请求级的 TPS： (100000(用户)×100(请求数))÷3600(秒)≈2,777.78(TPS) 2.单业务操作级 TPS： (100000(用户)×7(业务操作)))÷3600(秒)≈194.44(TPS) 3.用户级 TPS： (100000(用户)×1(用户级)÷3600(秒)≈27.78(TPS) 老师，关于上面这个计算，如果把业务模型加进去考虑，我下面这样的计算过程对不对，如果不对，帮我指点一下。 假设系统架构是jmeter-gateway-系统A-系统B-系统C-系统D，压力从gateway进来后，到系统A，系统A调用系统B通过feign调用，后面调用都一样，不走gateway。 实际上，每个用户不可能都会完成文中的7个业务操作，所以才会出现业务模型中各个业务之间的比例不是1:1的情况。 如果把业务模型考虑进去，我觉得多在线用户的TPS计算应该是这样。 1.请求级的 TPS： (从系统A,B,C,D的日志中统计出3600秒这个时间窗口内请求的总数量)÷3600(秒)≈请求级别的TPS 2.单业务操作级 TPS： (从gateway的日志中统计出3600秒这个时间窗口内各个业务操作的总数量)÷3600(秒)≈单业务操作级 TPS 3.用户级 TPS： 首先，从gateway日志中得到3600秒这个时间窗口的业务模型，假设业务模型为：登录20%,查询40%,添加购物20%,订单10%,支付10%， 其次，从业务模型还可以得到100个T（这个T指的是业务操作级别的事务）对应40个T（这个T指的是用户级别的事务），因为我们从第2步(单业务操作级的TPS计算)中已经得到3600秒时间窗口内业务操作的总数量，假设这个数量为a，所以a对应的用户级别的事务就是(40/100)*a， 所以用户级别的TPS应该这样计算： 用户级 TPS≈((40/100)*a)÷3600(秒)展开作者回复: 看起来你算的是对的哦。
1- byyy2021-07-07老师，我有2个问题，帮我解答下 1."在线用户数。这个值可以从日志中取到；" 在线用户数的计算原理是怎样的，怎么通过日志来得到在线用户数？ 2."请你注意，在这个逻辑中，我没有把业务模型加进来一起讨论，因为加了业务模型，反而会让问题变得更复杂。" 如果把业务模型加进去的话，是怎么样的逻辑？
作者回复: 1. 这要看日志中有没有这个计数器。在线用户数，有的系统放在日志中，有的放在数据库、缓存中。这个你要根据自己的系统来判断。 2. 请结合06篇一起来理解。
1 
A0桑荫不徙2021-06-24我们可以对应算一下，一个没有停顿的用户（并发用户）相当于多少个有停顿的用户（在线用户）呢？在这个转换的过程中，我们暂时不考虑请求的区别。 这个在线用户数不是统计出来的吗，咋还能计算呢，实在没明白，越想越想不明白，这个计算也没明白作者回复: 这个是为了计算并发度，在线用户总数是统计出来的。
1- sierlu2021-06-21老是我不是把压力线程当成用户了，我换一个问法，文中说的是10万用户再一个小时内操作一次业务流程，操作时长250s,通过计算并发用户是2400，并发度是2.4%，那10万个用户再一个小时内有停顿的操作，但是结束又循环操作业务流程（相当于每一个用户一小时应该操作了3600/250=14次），每次业务操作时长250 的并发度又该怎么算呢？在线用户数×无停顿时间的单线程TPS/有停顿时间的单线程TPS，按照老师的算法并发度还是2.4%。所以我感觉这个算法需要有个前提，就是这个一小时内用户应该是有停顿的操作完一次后，又循环去操作，求老师解答疑惑~谢谢老师～
作者回复: 我只是做个假设，前提是每个人操作一遍。如果有循环操作的话，那假设前提就变了。就得重新算了。
1 
言希2021-06-12首先在线用户数和并发度怎么算的？其实再第一个专栏中已经提出，而这个专栏是从1个用户的视角分析了在线用户数，大概意思是找出用户真实操作场景下的TPS，然后找出并发下的TPS，因为单一用户真实操作场景下用户再一个用户T中只执行了一次；那么反推真实操作场景下的TPS/1个用户下并发下执行的TPS数就是在线用户数；但是真实中肯定不会只有一个用户所以这个计算过程只是参考供大家思考即可；作者回复: 真实环境中要用真实的大量的用户来做统计才是正确的。 这篇主要是解释清楚其中的关键逻辑。
1