2019-12-25第一个问题：如何理解“服务端的并发能力”这一描述？
首先我们从数据视角来理解，可以把服务端程序用一个模型来看待，即由「网络 API 请求」所驱动的。
服务端的领域特征是大规模的用户请求，以及 24 小时不间断的服务。但某种意义上来说更重要的原则是：坚决不能丢失用户的数据，即他认为已经完成的业务状态。服务端必须保证其业务状态的可靠性，这时业务状态才持久化写入到外存。所以对于服务端来说，存储至关重要。它不只是极大地解放了处理效率，也是服务端的性能瓶颈所在。几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。
在衡量服务端的性能，我们还是要服务端视角来看，主要以 TPS 为主来衡量系统的吞吐量，如果有必要用并发用户数来衡量的话，需要一个前提，即响应时间（RT），因为在系统压力不高的情况下，将思考时间（等待时间）加到场景链路中，并发用户数基本还可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义，也不专业。
第二个问题：我为什么不提倡使用“绝对并发”和“相对并发”的概念呢？
我觉得一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，对这种难懂的概念很反感，要知道的其会加重内部沟通的难度，得不偿失。如果没那个价值，简单才是王道。
第三个问题：我们为什么不推荐用 CPU 来计算并发数？
比如单核CPU情况，实际上是只有一个的，在一个特定时刻也只可能有一个程序跑在一个CPU上(因为寄存器只有一组)，但是我们在上层观察到的却是系统上好像同时运行着那么多的程序，这实际上是操作系统用进程这个概念对CPU做的抽象。
同时如果你了解「阿姆达尔定律」，就知道多处理器并行加速，总体程序受限于程序所需的串行时间百分比，超过一定的并行度后，就很难进行进一步的速度提升了。并不符合线性关系，也无法估算的。
再说服务端程序性能依赖不仅仅是底层的硬件，其依赖的基础软件还包括：操作系统、编程语言、负载均衡、中间件、数据库或其他形式的存储等。在第一个问题中提到了几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。
最后，还是需要回到第一个问题，即由「网络 API 请求」所驱动的模型上来。展开作者回复: 不仅深得真传，还扩展了。 我看好你哦。
4 14
2019-12-25问题一，如何理解“服务端的并发能力”这一描述。对于web项目而言，服务端是整个项目的关键，是咽喉要道，因此也是性能测试的重点。测试目的当然是要摸清这个要道能同时走多少人（注意这里的人不是在线用户数并发用户数，而是服务器能处理的事务），因此TPS最能描述服务端的并发能力。虽然老师一直强调压力机并发线程数不是关键，但是公式表明其与TPS、响应时间有着不可分割的联系，还需要好好体会并运用。很期待基准测试以及如何判断响应时间、TPS合理的后续讲解。
问题二，为什么不提倡使用“绝对并发”和“相对并发”的概念呢？老师讲得很清楚了，这两个概念对于我们关心的性能并没有太多的帮助，反而让人有点无从使用。在线人数，并发数，并发度简洁明了，很好理解，有利于沟通，是性能测试必备指标之一。
问题三，为什么不推荐用 CPU 来计算并发数？并发数是业务逻辑层面的，而CPU只是众多软硬件环节中的一环，即使可以借鉴，肯定也是很粗略的估计，在实践中使用价值不大，没有推广使用的必要。展开作者回复: 这个理解太正确了。比我写的好。
2
2020-01-21服务端线程的工作情况图在哪里看呢老师？linux服务器上还是jmeter有监控插件作者回复: java的可以用jvisuamvm之类的工具看。
1- 2020-01-06针对吞吐量，根据你的公式， 我没计算出跟jmeter一样的值。我用jmeter 去压测(http://example.com/)，number of threads: 3, Ramp-Up:1, Loop Count:50, 平均响应时间：679ms, Throughput: 3.6/sec, 但是根据您的计算公式 1000/679 * 3 = 4.4。请高老师赐教。
作者回复: 去掉ramp up。
1 
2019-12-25老师，我们一般根据日志可以拿到在线用户数，但是并发度是百分之一还是百分之十这是全靠拍脑袋算的吗？作者回复: 通过统计每秒的业务请求数以及比例就可以知道并发度了呀。
可不能把脑袋拍坏了。 4 1
2020-01-21老师，这篇文章学到了很多以前概念认知偏差的盲点，期待后续课程，文章写的特别好，虽然有些地方还是有点难理解，需要多看几次😊 😊作者回复: 多谢支持。
2020-01-17对于并发度还不太理解。请问有历史线上数据的情况如何计算并发度，没有的情况又如何估算呢？能否分别举例说明一下。作者回复: 我觉得这个会是比较简单直接的过程，所以就没有细写。逻辑如下：
1. 统计某时段的当前在线用户数；
2. 统计同一时段的操作某个功能的用户数；
3. 把所有功能操作的用户数都统计出来；
4. 将统计出来的用户数除以在线用户数就知道并发度了。
2020-01-16老师，这个并发度怎么来的，文中并没有详细解释，一个新的系统，或者一个未压测过的系统，怎么来计算这个并发度呢？
我的理解是这样的请老师指教：
新系统的话，一直添加线程数，直到返回超时或者开始报错了，用这个值当做最大在线用户数，然后用TPS/最大在线用户数 然后得到并发度，这样计算是否正确作者回复: 不是的。并发度肯定是通过线上的数据统计计算得来的。
任何一个新系统，要说完全没有容量的预期，这个是不可能的。
2020-01-15老师您好，我使用Jmeter设置的线程数为100，循环2次，未设置Ramp-Up，聚合报告输出平均响应时间（Average）为118；使用你的公式计算得到的TPS为84.7；但是我看聚合报告的Received KB/sec为62.78。公式：TPS=（1000/Average）*10作者回复: 算瞬间值试试。
1
2020-01-14老师，看完您的讲解，我返回去看了一下之前测试过的一个聚合报告。我对一个线程组的测了100线程组的并发，该线程组下有两个接口，接口1平均响应时间83ms，接口2平均响应时间505ms，总的平均响应时间293ms。接口1吞吐量27.2，接口2吞吐量27，总吞吐量53.8。和您上面的这个公式是对不上的（TPS=响应时间(单位ms)1000ms∗压力机线程数）。想问下可能的原因是在哪里呢？作者回复: 场景中很多配置元素都会有影响，像ramp up，sleep之类的。这公式对每个瞬间的数据都是有效的。但对结果的平均值就得考虑很多因素了。
2020-01-13老师好，请问并发度是怎么算的呢？
您给的回复“通过统计每秒的业务请求数以及比例就可以知道并发度了”
请问这个可以举例吗？这个比例是什么呢？还是不太明白作者回复: 这个如果要详细说下来有点复杂。等我把这个专栏全部完成了。我考虑下做个实例出来描述具体的过程吧。
如果只是空口白牙的解释，我觉得怎么解释都显得空洞。
等我。
2020-01-10思考题：
• 如何理解“服务端的并发能力”这一描述：服务端并发，指的是从服务器真实处理的请求并发数量
• 我为什么不提倡使用“绝对并发”和“相对并发”的概念呢：并发要依附于场景而存在。脱离场景谈并发，可能性太多，无法实际衡量
• 以及，我们为什么不推荐用 CPU 来计算并发数：CPU数量和实际的并发数量持平。实际上，“并发”强调的是每秒处理的请求数，讲究 分时复用作者回复: 理解的基本没啥问题。
2020-01-09单个线程的tps是10、按照并发度计算的话、如果要求tps是1000的话、线程设置100就可以了，如果100个线程的tps达不到1000是不是就有瓶颈了？作者回复: 理论上是对的。只是实际上由于资源的调度会有稍微的降低。
- 2020-01-08对于视频类app，怎么衡量tps，感觉用tps衡量性能指标，也能局限性。
作者回复: 只是T的内容会不同，而不是T在这时有局限性。
- 2020-01-08并发度这个值应该怎么得出？估计除了已经上线系统看运维日志，其他情况拍脑袋居多
- 2020-01-08楼主，如果用jmeter作为压测工具，jmeter默认以线程替代了vugen，当刚开始压测时，连系统tps都得不到，怎么将并发用户数转化线程数了？
作者回复: 没看懂描述的问题。
- 2020-01-07Tps就是并发用户数，那压力机的并发线程数对于性能测试结论中又是处于什么地位呐？
不知道老师能不能理解我的意思，有些表达不清。作者回复: 压力机中的并发线程数是产生请求的。它和tps是强相关的。
之所以我不建议用压力机中的并发线程数来承载服务器端的性能指标，是因为并发线程数即不能描述并发用户数，也不能描述在线用户数。
我们通常在说服务端支持的并发用户数是指每秒能处理多少个用户的业务（也就是TPS）。 
2020-01-05老师你好，问个问题:
以前测试，项目上要求测出最佳并发用户数，我这边测出一个最大Tps，这个Tps对应的jmeter设置线程数就是最佳并发用户数。现在看了这篇文档，我现在可以认为Tps就是并发用户数吗？作者回复: 不可以。
再看一遍。
2020-01-04请教下，例如Jmeter压测，错误率一般达到多少时，TPS,RT那些参数就没了参考意义作者回复: 这个要看业务指标了。
在要求严格的业务指标中错误率会要求为零。像和钱相关的业务。- 2020-01-03根据文中描述，一个压力机线程，能测出来TPS是200，这个是怎么测算出的？需要用一个线程重复发送同一个请求多次？
作者回复: 一个线程迭代发送请求，这本来就是压力机的逻辑呀。
一个线程发一次是5ms。那1s就是发200次。不就是200tps嘛。