介绍
通过产品线数据分析,发现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合并需考虑后端成本,如果可接受建议使用;