聊聊如何衡量服务端性能

名词介绍

　　吞吐量：单位时间内处理的请求数（通常所说的TPS，QPS，其实都是吞吐量的一种衡量方式）

　　响应时间：处理每个请求所需的时间

　　并发数：服务器同时并行处理的请求个数

　　以上三者关系：并发数 = 吞吐量 * 响应时间

　　举例：一个单机单线程的系统，假设处理每个请求的时间是1ms，也就是响应时间是1ms，意味着1s可以处理1000个请求，QPS为1000。并发数 = 1000（QPS） * 0.01 = 1（也就是说，其同时处理的请求数是1，响应时间与吞吐量成反比）。

 

开聊

　　和并发相关不得不提的一个概念就是 QPS（Query Per Second），QPS 其实是衡量吞吐量（Throughput）的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求 —— 我们通常是指 HTTP 请求，显然数字越大代表服务器的负荷越高、处理能力越强。作为参考，一个有着简单业务逻辑（包括数据库访问）的程序在单核心运行时可以提供 50 - 100 左右的 QPS，即每秒可以处理 50 - 100 个请求。

　　但 QPS 只能粗略地衡量请求的数量，完全不关心服务器处理每个请求的开销。例如一个命中缓存的请求和一个需要进行多次数据库查询的请求的开销可能会有一个数量级的差距，所以 QPS 并不能十分精确地衡量服务器的负载或处理能力，因此我们引入了一个非常抽象的概念 —— 并发。

　　大部分请求的响应时间在 15 - 30 毫秒左右，这里的响应时间是指服务器处理这个请求所花费的时间，从客户端测量到的时间可能会稍长一些。想象如果服务器上只有一个 CPU 核心在逐个地在处理请求，如果每个请求花费 15 毫秒的话，那么每秒可以处理 66 个请求，也就是我们前面提到的 66 QPS；而如果都是复杂的请求，每个需要 30 毫秒的话，那么服务器就只有 33 QPS 了。可以看到在处理能力不变的情况下（只有一个核心），响应时间越高，QPS 就越低。又如果在响应时间不变的情况下，如果我们增加一个 CPU，QPS 就会翻倍，这三者之间的关系可以简单地描述成：吞吐量（QPS）= 并发数/平均响应时间［一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降］。

　　其实 CPU 的数量就是并发最基本的概念，即有多少个 CPU 在工作。当然在实际的服务器端环境中，我们在 CPU 的基础上建立起了进程、线程、协程这样复杂的抽象、通过异步的 IO 提高 CPU 的利用率 —— 当需要从硬盘或网络读取数据时，CPU 会去做其他工作，所以并发和 CPU 的比值会比 1 高一些，IO 越多，这个比值会越高。

　　这时我们可以观测到的并发数就是服务器在同时处理多少个请求，也即「并发连接数」。对于 Web 后端的场景来说（而不考虑**等长链接的场景），我们希望尽快地给客户端响应，所以请求在服务器端花费的几十毫秒中每一毫秒都是必不可少的：可能是在进行计算、也可能是在向磁盘或网络读写数据，都在占用着服务器的资源，因此并发依然是衡量服务器负荷和处理能力的关键指标。

　　除了并发本身，我们还经常提到「最大并发」的概念，最大并发就是在单位时间（通常是一天）里并发最高的那一刻有多少个 CPU 在为你工作。大部分应用的请求量并不是均匀地分布在一天中的，因为用户们往往会集中在傍晚的几个小时中使用手机，这些时段中的请求量要远远高于凌晨。所以人人都希望在傍晚得到更多的计算能力，但遗憾的是这些计算能力需要原子世界中的 CPU 去支持，你不可能在傍晚购买一批服务器然后在凌晨下掉（当然，这其实是云计算要解决的问题），所以为了支撑傍晚的高并发，我们必须去准备那么多的服务器、必须在凌晨让很多服务器闲置，因此其实我们只关心一天中最高的并发数 —— 这代表了我们需要采购多少硬件资源。

 

 

 

转载:https://blog.csdn.net/leyangjun/article/details/64131491