使用 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 了
|