imageserv和nginx压缩图片比对以及JNI和NGINX FILTER图片压缩结果

最新推荐文章于 2023-11-20 13:36:10 发布

原创最新推荐文章于 2023-11-20 13:36:10 发布 · 343 阅读

0 ·

CC 4.0 BY-SA版权

知识点汇总专栏收录该内容

9 篇文章

订阅专栏

本文对比了nginx、java JNI调用graphMagick以及nginx filter模块在压缩图片方面的性能。测试结果显示，nginx filter模块在处理图片缩放时表现出最优的性能，平均延迟最低，处理速度最快。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

都是将800x800的图片，缩放到160x160,并且剪切，以及打水印，，，测试结果如下：

nginx:

Benchmarking: GET http://img30.360buyimg.com:81/n2/g3/M00/00/32/wKjMZVM7nI0IAAAAAAGeM_ndiYEAAATngAMbOEAAZ5L364.jpg
100 clients, running 60 sec.
Speed=16483 pages/min, 3128748 bytes/sec.
Requests: 16483 susceed, 0 failed.
CPU平均在90%左右，处理图片最大延迟是：87毫秒左右，最小是81毫秒，很平稳

java :

[root@node101 ~]# webbench -t 60 -c 100 http://192.168.204.91:9090/n2/jfs/t4/1/0/106035/e8dc38c7/533b94b7N080a463e.jpg
Webbench - Simple Web Benchmark 1.5
Copyright © Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.204.91:9090/n2/jfs/t4/1/0/106035/e8dc38c7/533b94b7N080a463e.jpg
100 clients, running 60 sec.
Speed=3058 pages/min, 1431674 bytes/sec.
Requests: 3055 susceed, 3 failed.
CPU平均100%左右，处理图片最大延迟是：3758毫秒左右，最小是198毫秒，大部分都是1000～2000之间毫秒。

JAVA通过JNI调用C的graphMagick性能测试结果：
[root@91 bin]# pstree -p 45565 | wc
4834 4834 133388
[root@node101 ~]# webbench -c 1000 -t 60 http://192.168.204.91:4040/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
Webbench - Simple Web Benchmark 1.5
Copyright © Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.204.91:4040/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
1000 clients, running 60 sec.

Speed=15462 pages/min, 632158 bytes/sec.
Requests: 3321 susceed, 12141 failed.
平均延迟在3531毫秒，CPU在20%左右，大部分都在3000毫秒左右的延迟。

发现tomcat的线程数量是4834,，，查资料得知，graphmagick会自动开启openmp模式，这种模式下，就是会为每个线程自动开启24个后台线程来处理，tomcat总共是200个线程，因此总共是4800个线程

延迟增大到3000多毫秒，不可接受。

JAVA通过JNI调用C的graphMagick的测试2,降低OPENMP的自动开启的线程数，来测试：
export OMP_NUM_THREADS=1
[root@91 bin]# pstree -p 3133 | wc
237 237 6162
[root@node101 ~]# webbench -c 1000 -t 60 http://192.168.204.91:4040/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
Webbench - Simple Web Benchmark 1.5
Copyright © Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.204.91:4040/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
1000 clients, running 60 sec.

Speed=15341 pages/min, 630825 bytes/sec.
Requests: 3314 susceed, 12027 failed.
平均延迟在3465毫秒，CPU在20%左右，大部分都在3000毫秒左右的延迟。

发现tomcat的线程数量是237,，，查资料得知，graphmagick会自动开启openmp模式，这种模式下，就是会为每个线程自动开启24个后台线程来处理，tomcat总共是200个线程，因此总共是237个线程

延迟增大到3000多毫秒，不可接受。

通过C的多线程调用C的graphmagick库，看看结果如何：
平均延迟是2000毫秒左右，启动了237个线程数的结果，，

export OMP_NUM_THREADS=1 设置为1的测试结果。
在export OMP_NUM_THREAD=24d的时候结果和上述结果差不多

由以上结论得知，graphmagick虽然是多线程安全，但是线程数多了，会影响延迟和结果。
因此考虑采用nginx filter模块来测试结果：
cpu 24个core全部在98%左右，，平均延迟在85毫秒左右有，，最大的延迟是88毫秒。。。节本上都在88毫秒。。

[root@node101 ~]# webbench -c 1000 -t 60 http://192.168.204.91:82/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
Webbench - Simple Web Benchmark 1.5
Copyright © Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.204.91:82/n2/jfs/t7/2/0/106035/e8dc38c7/533921fdN745313af.jpg
1000 clients, running 60 sec.

Speed=26809 pages/min, 3083813 bytes/sec.
Requests: 16188 susceed, 10621 failed.
该模块采用nginx filter异步模式来做图片的缩放，，，该模块将一个106K的图片缩放后变成了10K大小的图片，并且采用完全异步的模式进行缩放。

当tomcat处理完了数据发给nginx之后，因为这一步是异步的，所以filter模块也是异步的读tomcat给的数据，然后看看是否读完，如果读完则进行图片的缩放

如果没有读完，则去读取其他请求返回来的tomcat数据，，这样完全做到了异步处理。。。

使用这种模式，，总共是24个nginx的进程，每个nginx进程是单线程。。。。该模块已经开发完毕和测试完成。

以上是我这两天的测试结果，敬请各位指正。

icc编译器重新编译graphmagick测试结果
[root@b28-12106 ~]# webbench -c 1000 -t 60 http://192.168.12.177/n2/jfs/t1/1/0/80202/2509c0ec/53461384N40dd7150.jpg
Webbench - Simple Web Benchmark 1.5
Copyright © Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.12.177/n2/jfs/t1/1/0/80202/2509c0ec/53461384N40dd7150.jpg
1000 clients, running 60 sec.

Speed=21327 pages/min, 156220 bytes/sec.
Requests: 21323 susceed, 4 failed.