请问：接口的 rps 低受什么影响？

[mentalidade]

使用 libvips 做图片裁剪处理。

写完测试接口，time curl "http://wyc.com:8888/5e9564282f61b0e925a41bd1ac688a48?p=1&w=451&h=451" 接口响应很快：

real	0m0.042s
user	0m0.004s
sys	    0m0.005s

使用 ab 压测：ab -n 1000 -c 100 "http://wyc.com:8888/5e9564282f61b0e925a41bd1ac688a48?p=1&w=451&h=451" 结果 rps 很低

Server Software:        openresty/1.11.2.2
Server Hostname:        wyc.com
Server Port:            8888

Document Path:          /5e9564282f61b0e925a41bd1ac688a48?p=1&w=451&h=451
Document Length:        22921 bytes

Concurrency Level:      100
Time taken for tests:   13.543 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      23073000 bytes
HTML transferred:       22921000 bytes
Requests per second:    73.84 [#/sec] (mean)
Time per request:       1354.314 [ms] (mean)
Time per request:       13.543 [ms] (mean, across all concurrent requests)
Transfer rate:          1663.74 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.7      0       4
Processing:    35 1281 833.9   1137    4821
Waiting:       35 1280 833.9   1137    4821
Total:         36 1281 834.0   1137    4822

原来用的 GraphicsMagick 处理，这个 libvips 确实快了许多，内存占用还没测，不过 rps 都很低。

请问：这个 rps 受什么影响，会导致这么低，该如何优化呢

[knightdf]

一般叫 qps, 主要受后端逻辑处理时长影响

[mentalidade]

@knightdf 取出图片，因为存在类似于 redis 中，取出不处理直接原图输出，qps 可以达到 4000 多，然后缩放裁剪到一定的比例，再输出导致 qps 急剧降低。不过即使处理图片，单个请求是很快的，50 毫秒左右，就是输出 hello，world 也要 17 毫秒呢。
就是 qps 低的可怕

[RubyJack]

cpu 密集型，一般量大以后都是 context switch 的开销

[crohn]

注意做好处理结果缓存，其他的资料不足没法分析

[mentalidade]

@crohn 会的，一般客户端都是缩放到一定比例，服务器会根据请求把要裁剪的图片处理后再次存放。如果已经存在直接就从 redis 取出来，没有的话处理完存放进去。
如果已经存在缓存中的话，qps 会达到 3000-5000 的样子。
想查的话需要什么资料或者有什么工具吗？

[mentalidade]

@RubyJack 是的，从缓存中取出来就很快，不放入缓存，处理的话，qps 真的低

[mentalidade]

@RubyJack 确实是，本地压测的时候 Nginx 的四个 woker 的 CPU 占用都在 90%多，压测结束回归到 0 了