• 随着施压侧并发请求数增加，其每秒的响应数能继续增加，说明服务未到达瓶颈，服务可支撑的 qps 仍然未到达。
• 当并发请求数到达某个值后，若继续增加，每秒的响应数保持稳定，同时延时开始增加，说明在特定资源配额下，服务到达最大能支撑的 qps 数。
• 服务到达最大能支撑的 qps 数，通常是因为某项依赖资源到达瓶颈。木桶原理，最先到达瓶颈的依赖资源决定了服务在此资源配额下的最大 qps。
• 假设服务依赖 A、B、C 三个资源，当服务压测时到达最大能支撑的 qps 数时，若增大 A、B 的资源量，最大 qps 不变，而增加 C 资源量时，最大 qps 相应增加，说明瓶颈点在 C。
• 依赖服务，比如 web 服务的 mysql 或者 nginx 的 upstream backend 也可以抽象为依赖资源来计算，单位为 qps。比如 LB 依赖的资源有： cpu、内存、upstream 后端的响应能力。以同样的逻辑可以判断压测 LB 时，瓶颈是否出现在 upstream 后端上。

问题：假设单机资源可以无限增加（注意是单机），就也是资源永远不会到达瓶颈，是否服务在此单机下，qps 能无限增加？
大多数场景下不是。当 qps 增加时，即使单机资源能无限增加，但是很可能其增加趋势不是呈线性增加的。也就是当 qps 到达到一些量级的时候，其单位 qps 消耗的资源会呈指数增长。
比如 nginx，为了支持 qps 的增加，cpu 核数增加，其 worker 进程数也得增加，worker 进程数的增加本身会带来额外资源的消耗，比如内核调度和维护大量的进程等，这就可能导致 cpu 增加而能支撑的 qps 并不是跟着线性增长。
当压测时，性能瓶颈出现在 A 资源（或依赖），此时优化 B 资源（或依赖）的处理时间，对并发量没有任何提高的，只是会减少平均响应延时。 相反，此时优化 A 的处理时间，则可以提高并发量，因为 A 的处理时间减少了，单位时间内的处理量增加了，相当于提高了 A 能支撑的并发量，或者说相当于在特定的并发量下，节省了 A 资源的使用量，故节省出来的资源能支持更多并发。

• 一个服务最大并发数其实是：请求 X 服务时，假设 X 服务分别在使用 A、B、C 资源（或依赖）部分的操作为 XA、XB、XC，则其并发数实质为 A 对 XA 支持的最大并发数、B 对 XB 支持的最大并发数、C 对 XC 支持的最大并发数中最小的那一个数值。

可以想象 X 为异步非阻塞 web 服务器某接口，A 为 cpu 处理，B 为 mysql 处理，C 为 redis 处理。

最后更新于 2020-07-29 07:21:56 并被添加「」标签，已有 3286 位童鞋阅读过。

本站使用「署名 4.0 国际」创作共享协议，可自由转载、引用，但需署名作者且注明文章出处