这是一个创建于 2972 天前的主题，其中的信息可能已经有所发展或是发生改变。
使用 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 受什么影响，会导致这么低，该如何优化呢
 | 1 knightdf 2017-08-30 15:37:19 +08:00 一般叫 qps, 主要受后端逻辑处理时长影响 |
 | 2 mentalidade OP @knightdf 取出图片，因为存在类似于 redis 中，取出不处理直接原图输出，qps 可以达到 4000 多，然后缩放裁剪到一定的比例，再输出导致 qps 急剧降低。不过即使处理图片，单个请求是很快的，50 毫秒左右，就是输出 hello，world 也要 17 毫秒呢。 就是 qps 低的可怕 |
 | 3 RubyJack 2017-08-30 15:56:52 +08:00 cpu 密集型，一般量大以后都是 context switch 的开销 |
 | 4 crohn 2017-08-30 16:00:03 +08:00 注意做好处理结果缓存，其他的资料不足没法分析 |
| 5 mentalidade OP @crohn 会的，一般客户端都是缩放到一定比例，服务器会根据请求把要裁剪的图片处理后再次存放。如果已经存在直接就从 redis 取出来，没有的话处理完存放进去。 如果已经存在缓存中的话，qps 会达到 3000-5000 的样子。 想查的话需要什么资料或者有什么工具吗？ |
| 6 mentalidade OP @RubyJack 是的，从缓存中取出来就很快，不放入缓存，处理的话，qps 真的低 |
| 7 mentalidade OP @RubyJack 确实是，本地压测的时候 Nginx 的四个 woker 的 CPU 占用都在 90%多，压测结束回归到 0 了 |
Select Language