作者回复: 不仅深得真传,还扩展了。 我看好你哦。
作者回复: 这个理解太正确了。比我写的好。
作者回复: 通过统计每秒的业务请求数以及比例就可以知道并发度了呀。
可不能把脑袋拍坏了。
作者回复: 你这个结果看起来是不太对。要不你加我微信发详细点的数据我看看:Zee_7D
第二次回复:根据这位同学的反馈,他加了定时器。这样就导致了压力工具中真正的并发线程数不再是设置的线程数了。
吓了我一跳,我还以为久经杀场的最简单的计算逻辑出了大漏洞呢。哈哈。
作者回复: 后面有几篇讲到录制脚本,编写脚本。如果你要非常完整的,那就看帮助就行。不会的可以问,毕竟这个专栏不是工具类的。
作者回复: 在另一条留言中已经回复。
作者回复: 10个是压力机上的线程数。
前面说的5是服务端开的tomcat线程数。
作者回复: 对应到真实场景是说现在有7924个用户在线,而同时在执行登录这个操作的只有196.2个人。
作者回复: 这个非常简单,压力过程中观察线程的使用率和上下文切换频率就阔以啦。
作者回复: 后续篇幅中有详细的推演过程。😀
我已经为你这样的问题做好了准备。
作者回复: tps中的s就是秒呀。
作者回复: 基本正确。第3个主要是CPU不能代表系统的综合能力。
作者回复: 第三点需要稍微纠正,不是没有理论依据。是这个依据还不足以支撑计算业务的性能TPS。
作者回复: 把TPS调到最高就好。压力大,响应时间长了,tps下降了,那服务端的处理能力明显是下降了嘛。
不是用TPS来定义并发用户线程数,这两者的关联关系,只有在执行过程中确定,没有谁定义谁。
作者回复: 这也不是绝对并发的意思。
而是秒杀场景。
作者回复: 阔以滴。