对gin-limit这个中间件的疑问

Question

题目描述

偶然在开源项目中看到使用了 gin的limit中间件 , 看到作者描述的压测工具有点疑问

我的理解是:

qps = 并发/响应时长
那么在并发降低的情况下,响应时长如果没有到达系统瓶颈的情况下不变的,那么qps应该是下降的?

和我理解不符的地方:

可是作者这个压测带来的是直接的qps提升.

Everyone loves synthetic benchmarks, so have some numbers from my 2015 Macbook (on a fast rendering page; single sqlite query, basic templates).

% wrk -t12 -c400 -d20s http://localhost:4560/
Running 20s test @ http://localhost:4560/
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev

Latency   848.63ms  525.39ms   1.64s    62.81%
Req/Sec    45.43     61.85   360.00     90.50%

8908 requests in 20.10s, 21.91MB read
Socket errors: connect 0, read 219, write 0, timeout 0
Requests/sec: 443.19
Transfer/sec: 1.09MB
Now 10x faster with limit.MaxAllowed(3) (although that would be higher in the real world). Hooray!

% wrk -t12 -c400 -d20s http://localhost:4560/
Running 20s test @ http://localhost:4560/
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev

Latency    94.40ms   32.65ms 656.72ms   86.44%
Req/Sec   351.61     84.32   666.00     79.32%

84181 requests in 20.09s, 207.05MB read
Socket errors: connect 0, read 165, write 0, timeout 0
Requests/sec: 4189.75
Transfer/sec: 10.30MB

问题:

所以不解,请教下大家这是为啥?

Answer 1

你好,
首先, QPS 是每秒处理的请求数, 并不是 并发/响应时长 , 请求并不并发没关系.
其次, 简单来说, 并发的处理能力实际要看CPU的内核有几个, 如果4核的CPU, 那么其实它理想情况下并发就是4, 超多4个线程就会等待.

所以限流之后, 服务处理的线程小于CPU核数, CPU不用调度, 直接处理, 所以 QPS提高了.
未限流之前, 服务处理12个线程, CPU需要调度(具体要看CPU的调度算法), 轮流处理12个线程的内容, 跟限流方案比, 多了调度的过程.

这是我的理解, 供参考!