静态图片优化技术研究
2012-07-17 14:52:20   来源：我爱运维网   评论：0 点击：

         这两天对Image Optimization做了一些研究和测试，下面是相关研究和测试步骤，也请大家一起看看是否有毗漏或者可以进一步改进：
 
1.     优化原则和测试方法
l  优化和测试范围及对象：目前仅针对Jpg
l  测试数据源:来自WEBCDN访问日志中Top 302个经常访问的JPG图像，总大小为4704772，个数302
l  优化理论及原则:
n  无损压缩
u  移出图片中Meta Data和JPG EXif头信息
u  Optimize Huffman table(Baseline)
u  使用渐进效果优化（progressive）
n  有损压缩：由于对图片类型和场景需要深度考虑，此次测试和优化不考虑该场景
l  测试工具和方法
n  测试工具
u  Tengine(1.2.5) + image_filter+ image_filter_jpeg_quality
u  Yahoo YSlow(2.x) Smush.it
u  Jpegtran V8d
u  ImageMagick 6.5.7-7
n  测试方法和步骤
u  测试方法
1.         由于Yahoo Yslow为事实上web优化标准，所有测试和优化将以Yahoo测试结果为基准。
2.         调用Jpgtran和ImageMagic命令行对图片文件进行重写
3.         对图片基于Baseline(Optimize Huffman table)和渐进效果优化(progressive)
u  测试步骤
1.         将所有图片映射到HTML供nginx和SmushIT测试
2.         使用SmushIT测试得到基准优化数据
3.         对图片进行Jpegtran转换，包括Baseline和progressive，测试命令如下
n  Baseline
#jpegtran -copy none -optimize -perfect src.jpg > dst.jpg
n  Progressive
#jpegtran -copy none - progressive -perfect src.jpg > dst.jpg                                               
                                                                           由于ImageMagic和Jpgtran类似，偏重于API调用，由于时间原因，本次测试不涉及到ImageMagic相关测试。
 
2.     测试结果和分析
A.        Tengine+ image_filter_jpeg_quality 发现设置并没生效，IE访问得到JPG文件比对Server源文件MD5值相同，初步分析image_filter_jpeg_quality源码，其使用libjpeg对jpg图像进行quality处理，但实际运行中并没有触发相关逻辑，需要相关debug去发现问题，目前没有做相关调试。
B.        SmushIT 测试发现其优化193张图片压缩比在17%，另外99张图片SmushIT没有做任何处理，比对测试数据发现已经优化的193张图片和我们使用Jpegtran progressive处理效果一致，详细测试结果请参照附件测试数据。
u  下表是193张压缩数据对照：Jpegtran Progressive+BaseLine 为对大于10k文件使用Progressive，小于10k使用Baseline
 

测试工具	原始文件大小 (Byte)	优化和处理结果 (Byte)	优化大小 （Byte）	% 压缩比率
Nginx	4307508	4307508	0	0
Yahoo SmushIT	4307508	3561597	745911	17.31%
Jpegtran Baseline	4307508	3641432	666076	15.46%
Jpegtran Progressive	4307508	3561597	745911	17.31%
Jpegtran Progressive+BaseLine	4307508	3389109	918399	21.32%

 
u  下表是SmushIT没有做任何处理的99张图片,使用jpegtran处理后的相关数据:          
                           

测试工具	原始文件大小 (Byte)	优化和处理结果 (Byte)	优化大小 （Byte）	% 压缩比率
Nginx	397264	397264	0	0
Yahoo SmushIT	397264	397264	0	0.00%
Jpegtran Baseline	397264	396823	441	0.11%
Jpegtran Progressive	397264	408372	-11108	-2.80%
Jpegtran Progressive+BaseLine	397264	396026	1238	0.31%

 
u  所有图片优化结果综合:
 

测试工具	原始文件大小 (Byte)	优化和处理结果 (Byte)	优化大小 （Byte）	优化空间占整个文件比率
Nginx	4307508	4704772	0	0
Yahoo SmushIT	4704772	3958861	745911	15.85%
Jpegtran Baseline	4704772	4038255	666517	14.17%
Jpegtran Progressive	4704772	3969969	734803	15.62%
Jpegtran Progressive+BaseLine	4704772	3785135	919637	19.55%

 
C.        Jpegtran CPU 消耗，选取超过100k和压缩比超过75%图片得到一下CPU使用数据：
a)         230k  Jpegtran Baseline
real    0m0.493s
user    0m0.028s
sys     0m0.020s
b)         230k  Jpegtran Progressive
                            real    0m0.128s
user    0m0.120s
sys     0m0.000s
测试结论
A.   Yahoo SmushIT 使用和Jpegtran Progressive类似算法对图片进行压缩处理，压缩选取原则目前无法获取
B.   对于小于10k文件使用Baseline能得到最优化结果
C.   对大于10k文件使用Progressive能够得到最优结果
D.   对测试样本使用Jpegtran Progressive+BaseLine压缩后，能够得到20%带宽节省。
3.     优化方案
根据上面测试结果和相关参考材料(相关材料请参考附件)，提供一下两个优化方案
A.   Inotify+ Jpegtran
n  对已经存储静态文件使用Jpegtran进行批量处理，大于10k使用Progressive处理，小于10k使用Baseline
n  对新上传文件使用Inotify进行监控，对出现OnCreate和Onmodify的jpg文件触发Jpegtran进行处理
n  缺点:图片存在延迟，即文件上传后10-30s后才会得到更新,需要双份copy占用存储空间。
n  优点：对研发透明，不需要调整现有模式和程序
B.        ImageMagick php等API
n  使用ImageMagick php等API对现有程序进行改造，上传图片后直接处理。
n  已存图片使用Jpegtran进行批量处理
n  优点:对运维透明，变更小
n  缺点：要大规模调整图片上传程序，稳定性需要验证
 
相关资料和文档：
 
http://jpegclub.org/jpegtran/
http://zh.wikipedia.org/zh-cn/Jpg
http://zh.wikipedia.org/zh-cn/Category:%E8%89%B2%E5%BD%A9%E7%A9%BA%E9%97%B4
http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/
OReilly.Even.Faster.Websites : CHAPTER 10 Optimizing Images
imgImage Optimization for the Web at phpworks8