服务端性能

我们常在狭义上说的“服务端性能”，其指的就是 TPS[QPS] 。即在定义的响应时间内(如 200ms 标准)，以及定义的成功率下(如 90% 、95%、99%等)，所统计的到达服务器且被其成功处理的每秒事务数。

那么在性能测试中，往往会听到一些让人模糊的术语，为此简要说明

线程与用户并发数、TPS

下文的 TPS/QPS 默认指的是对应一个请求，非压测工具中插入的“事务”起止而定义（因为插入的“事务”通常是业务概念，非技术概念）

我们提到“并发”时，都知道离不开“线程”，而性能压测工具如 LR 中的“虚拟用户数 VU”、Jmeter 中线程组的“线程数”，便与“用户并发数”存有一定的关联(非直接关联却有直接的影响)。怎么理解？先明确重点——假定在定义结果中 TPS 为 1000/s ，即意味着相当于服务器在 1s 中可以完成 1000 个已达的请求同时处理。

举个栗子，当设定用户线程数为 100，在 10s 内完成启动，循环次数不限。这相当于这 100 个用户线程反复 10 倍的请求且在 1s 内被服务器成功处理①；又或者为 x 个在 y 秒内完成启动，理论上无论怎样换算，最终结果相当于 1000 个用户在 1s 访问成功 。也就是说，用户线程数、线程加载/启动时间，与 TPS 本身没有等价关系（或者说换算公式）。

但是，用户线程数和线程加载/启动时间，对于 TPS 确实有直接的影响——因压测模型的设计不贴合实际流量情况，导致服务器性能的变化，也就是 TPS 变成了不准确甚至错误的结果。比如上述的 100 线程在 10s 完成启动并循环 n 次，或者 50 个线程在 10s 完成启动并循环 n 次，或者 100 线程在 20s 完成启动……在没有“集合点”②的情况下，每个线程均是启动后就立即执行请求，可以想象成一个个的运动员在跑接力赛，每个运动员起跑(启动时间)和奔跑的速度(获得线程锁并完成执行)有快有慢，而起跑速度的快慢会导致新的运动员(线程)启动有快有慢(当然的，肯定在指定时间完成启动)，而裁判(服务器)规定了在限定达到时间(1s)内都分享奖金，因此运动员的数量和速率都会对结果造成影响。切回技术层面换句话说，也就是线程(用户)数和启动时间将影响 TPS ，可能高于或低于 1000TPS

再回看前文-指标与参考计算公式，结合起来即能理解到：

① 可能细心的你，结合对于技术原理的掌握，可能会抛出新的疑问。诸如：那为什么不干脆设定成 1000 个虚拟用户/线程数？session / token 是一类唯一标识，那不始终就是这 100 个用户吗？创建 session / token 也是需要开销的，这样如何准确？这个要阐述清楚，确实比较复杂，但是几乎在非特定业务情况，服务器只关心连接/请求数量而不在乎是不是同一个用户，又或者是不是来自同一个用户的请求。你只需要记住性能压测/负载测试，均只能仿真。如同软件世界里实现的“随机数”一样

② 压测模型中设置集合点只可能是因确切的特定业务模式而需要