「侦探价格」「性能测试实战30讲」之问题问答整理二

能有这种的评论，我认为最自豪，有认同感。我受到概念扰乱多年，总是得和人解释一顿我觉得对的概念跟操作模式。

02

精彩问题

摘抄自留言区精彩的提问。

Q:

性能检测通过概念、模型、观测、实验等方式来进行问题的解读。其涵盖范围之广，从压力工具、操作系统、开发语言、数据库、消息队列、中间件、网络等各个方面。通常还必须深入的理解各种机理，特别是在一些重点细节上，往往必须有超过通常的了解跟技巧。

A:

深得真传呀。哈哈。

Q:

有全链路压测相关的实战吗？

A:

这个话题说大不大说小不小，在这个专栏中，我没打算讲全链路压测相关的话题。不过即使这里问到，我估计描述一下我不准备写的缘由。全链路压测是两个部分。全链路 和 压测，压测部分要做的就是有清晰的标志，而全链路就是系统要做的链路改造。从技术层面说，不管是使用相同的软件做旁路应用，还是改造已有应用做链路标识识别，技术的谋求手段都是成熟的。我今天在设计一个全链路压测的模拟平台，开发迅速就能做得起来。但是全链路的瓶颈在平台的庞杂和队伍之间合作的推动。所以全链路是个管理协调的难度高于技术推动的事情，并不像很多人所说的这么高高在上。

Q:

后面会有全链路压测的讲解吗？

A:

没计划写全链路。这个话题可大可小。做个综述类型的觉得不落地，要是写细节，感觉一个新专栏都有了。后续我考虑一下再决定怎样写，即有落地又不至于写很多。

Q:

老师我想问一下理发店模型是哪个模型？

A:

理发店模型也是排队论中的一个demo，单独拆下来理发店，不能称为模型。像这种的demo我可列出一堆来：1. 火车站售票窗口；2. 医院就医；3. 早餐鸡蛋灌饼摊；4. 地铁口；5. ......，所有能排队的地方都是这样的demo。

Q:

1、性能检测工程师就是全栈工程师喽，真正业内有多少可以超过？2、性能检测工作必须其他人参予吗？3、分布式平台与单机系统在性能上有无差别？若有差异，差別在哪儿？

A:

1，不一定是一个的应该全栈，一个团队能做到即可，甚至虚拟团队也可以，只要做好项目管理。2，当然是必须的，主要看性能团队原本能做到什么程度。程度越深，和其它团队的沟通越流畅。如果连推动性能问题定位预测的素质都没有，那就只好做性能验证了。3，显然这二者有巨大差异。分布式平台首先应做的就是响应时间消耗的监控拆分。定位至某节点后再定向分析。

Q:

感谢老师分享性能知识，从业务建模到实地开展工作，从基本功夫到工作价值凸显，任何理论只有落地才能形成价值，才是有用得理论，不能拿书本中这些理论做对比，咱们从事工作分两方面造成价值，一方面减少精度，一方面提升品质。老师从这两方面下手，解决根本疑问，让从事这方面得工作员工展示自己价值。

A:

深得真传了。哈哈。

Q:

因为其实的性能检测方式概念混淆，但是目标既更接近，边界也不明确，目标仍基本一致，所以舍弃概念，追逐目标，就是系统指标改进。另外性能检测的核心调优需要链路式的剖析，监控才能帮助印证这种模式。

A:

深得真传！

Q:

QPS=并发数*常数/RT , 也就是到瓶颈后加并发后RT增加QPS不变，那么瓶颈基本在RT增加的节点上

A:

你理解的太对。对性能来说，性能瓶颈肯定是在RT增加的节点的

Q:

有个难题想询问一下老师：关于TPS与并发线程数，正常需要是以TPS作为平台容量的考量标准，这个在平台性能比较好的之后很好和客户沟通（即TPS>并发数）。但是在平台性能较低的项目中，有时候就很难和用户沟通，比如一次项目中「情感测试题」，系统在2000并发，系统TPS就到了最大1500多，RT、资源利用率那些也还好；但是接着增加并发至5000时，TPS基本相当平稳，没有什么下降，响应时间才刚刚超时。对于这些状况，在计算平台能支撑最大在线数量时，客户就认为应当按照最大并发数5000去算（RT可接受时），而不是依据最大系统TPS1500多去算，他们认为你的每1个并发都是模拟的1个用户在实际使用，而响应时间没超时，就表明可以支撑这个并发数的客户同时使用（假设并发度100%时）。我从响应时间预测，感觉人们的表述也没毛病，但是理智告诉我，从TPS看系统每秒最大也能够处理1500多，其余的请求需要会在队列超时，或被拒绝，但是5000并发持续压测10分钟，也没看见大量超时或报错（千分之一以下），拿不出证据来支撑，感觉真是性能三观都要被改变，一直耿耿于怀，还请同学解惑！