介绍
通过产品线数据分析，发现70%左右的图片为小于300K的图片，50%左右为小于100K的图片，因此调研前端图片合并方案是否有利于提高图片批量上传速度。之前做过的前端ZIP方案也是类似的思路。
工具
- 使用Network Link Conditioner模拟各种网络环境；
- 使用
sprites/index.html测试前端合并的效率； - 使用
zip/index.html中的NOZIP方案测试无合并的效率；
前端合并方案
- 采用Canvas将小图片拼接到单列上得到合并后的图片；
- 将合并后的图片发送到服务器端；
测试维度
- 网络环境: 10K 100K 300K 500K无网络延时以及50K带100ms网络延时；
- 图片大小: 100K
- 并发数：1 - 5
- 图片数量：50
数据
*说明：未计算服务器端将合并后图片拆解所需时间；
speed = 256 K/S delay = 5ms(ADSL)
T 1 2 3 4 5
Sprites(ms) 148563 146993 146910 147149 147957
Normal(ms) 203878 184155 187438 183793 183533
% 28 20 22 20 19
speed = 10 M/S delay = 1ms(WIFI Good Connectivity)
T 1 2 3 4 5
Sprites(ms) 2356 1495 1264 1202 1208
Normal(ms) 3322 1891 1524 1290 1221
% 29 20 17 7 1
speed = 500 K/S delay = 0
T 1 2 3 4 5
Sprites(ms) 8904 8622 8471 8434 8444
Normal(ms) 11326 10770 10183 10980 10181
% 21 20 17 23 17
speed = 300 K/S delay = 0
T 1 2 3 4 5
Sprites(ms) 14377 14352 13951 13927 13924
Normal(ms) 17636 16961 16972 16975 17001
% 18 15 17 18 18
speed = 100 K/S delay = 0
T 1 2 3 4 5
Sprites(ms) 41549 42185 41973 - -
Normal(ms) 51796 53401 51758 - -
% 20 21 19 - -
speed = 10 K/S delay = 0
T 1 2 3 4 5
Sprites(ms) 414722 - - - -
Normal(ms) 538864 - - - -
% 23 - - - -
speed = 50 K/S delay = 100ms
T 1 2 3 4 5
Sprites(ms) 90348 88913 88996 90615 -
Normal(ms) 139343 125771 110348 109680 -
% 35 29 20 17 -
分析
- 并发（2-5个请求）与不并发（1个请求）在高速和低速网络环境下效率表现有差异。在低速下，由于单个请求的速度已占满带宽，并发时每个请求的速度均会被平分，从而并发与不并发无明显差异。而高速下单个请求的速度并不能占满带宽，并发时每个请求的速度不会平方，从而导致并发对网络使用效率更高，拥有更高的传输速度；
- 合并方案在上传效率上总体优于不合并方案，优势在单请求时达到最大（速度最大能提升35%），随着请求数增多，优势也在收窄。原因在于，并发对于不合并方案而言拥有比合并方案更大的收益：并行连接以及连接重用，减少网络延时成本。而对于合并方案不存在连接重用，而并发本身在低速下无法提速，从而导致优势收窄；
- 合并方案对于不合并方案的优势在高延时网络下最大。因为合并方案相比不合并方案最大的优势是节省请求，因此当网络延时增大时，每个请求的时间会变长，而这对于合并方案的影响非常有限，但对于不合并方案则会成倍增加。
与ZIP方案相比
- 图片合并效率比ZIP效率快
10倍左右，因此图片合并更适合图片上传； - ZIP方案效率更低，但可以适用于所有文件类型；
结论
- CANVAS合并方案批量上传效率整体优于无合并方案，上传速度提升平均20%；
- 合并方案适合用于网络延时较大的网络环境，降低网络连接成本；
- CANVAS合并需考虑后端成本，如果可接受建议使用；
