码迷,mamicode.com
首页 > Web开发 > 详细

文件批量上传ZIP方案调研

时间:2020-05-29 14:00:49      阅读:76      评论:0      收藏:0      [点我收藏+]

标签:环境   ajax   前端   一个   for   and   img   维度   sock   

介绍

利用HTML5的新接口例如ArrayBufferBlob等可以在前端进行zip操作并且可以将zip后的文件上传到服务器。本调研主要关注zip方案的zip效率以及整体上传效率。

工具

维度

  • 网络环境:2G & 3G & wifi
  • 图片大小:50K & 100K & 300K
  • 并发数:1 & 3(仅针对NOZIP方案)
  • 图片数量:30

方案

ZIP方案:上传前采用前端ZIP方法将所有文件打包成一个文件后使用AJAX上传,需记录打包时间和上传时间;
NOZIP方案:采用并行1或3个AJAX请求的方式批量上传所有的图片;

数据

2G

使用Network Link Conditioner模拟2G环境,上传速度在15K/S左右,每个请求建立连接的时间在1s左右;

方案 50K 100K 300K
ZIP 82285 146951 498930
NOZIP1 168294 236620 592867
NOZIP3 96198 156123 499195

技术图片

2G网络中只保持1个请求的情况下,ZIP方案具有绝对的优势,尤其在图片大小小于100K时。

2G网络中同时开启3个请求的情况下,当图片大小小于100K时ZIP方案有比较明显的优势,但是随着图片尺寸的增加这种优势逐渐消失。
ZIP方案的优势在于将N个请求合并成1个,因此有效减少了每个请求中除去上传数据之外的额外时间,例如连接建立等。

对于非ZIP方案而言,在图片尺寸较小时,每个请求中非图片上传的时间占更大的比例,因此ZIP方案的优势得以突显,而随着图片尺寸的增加,每个请求中非图片上传时间的比例也在下降,因此ZIP方案没有明显优势。

此外,与串行请求相比,在2G环境中使用并行请求仍然能获得优势,例如在串行时NOZIP方案上传30张50K图片耗时约181878ms,与3个请求并行相比慢了约1倍。原因在于并行时请求建立连接以及服务器端的处理都是并发的,而不像串行时所有前端和后端的处理均为线性。

请求数据:

通过Chrome开发者工具看到的每个请求包括:

  • DNS Lookup: Time spent performing the DNS lookup. You want to minimize DNS look ups.
  • Connecting: Time it took to establish a connection, including TCP handshakes/retries, DNS lookup, and time connecting to a proxy or negotiating a secure-socket layer (SSL).
  • Sending: Time spent sending the request.
  • Waiting: Time spent waiting for the initial response.
  • Receiving: Time spent receiving the response data.

以上的解释似乎都理所应当,但查看实际的数据时仍然会有令人困惑之处,主要集中在SendingWaiting

例如以下是一个2G环境中上传50K图片时的请求数据:

  • DNS Lookup:0
  • Connecting:850ms
  • Sending:0
  • Waiting:5.54s
  • Receiving:0

例如以下是一个2G环境中上传1.2M图片时的请求数据:

  • DNS Lookup:0
  • Connecting:846ms
  • Sending:47.3s
  • Waiting:5.54s
  • Receiving:0

例如以下是一个wif环境中上传50K图片时的请求数据:

  • DNS Lookup:0
  • Connecting:5ms
  • Sending:0
  • Waiting:24ms
  • Receiving:0

例如以下是一个wif环境中上传300K图片时的请求数据:

  • DNS Lookup:0
  • Connecting:4ms
  • Sending:189ms
  • Waiting:22ms
  • Receiving:0

从数据可以看出,Waiting并不是纯服务器端处理时间,它与网速有直接关系,wifi下的Waiting时间是接近真实的服务器端处理时间的。
但同时Waiting时间与文件大小是无关的,无论50K还是1.2M都基本一致。
初步猜想Waiting包括一部分浏览器处理文件上传的时间,否则在15K/S的上传速度下,50K文件的Sending时间不应该是0。
此外,Sending时间与AJAX中progress监控的时间保持一致。

综上所述,2G环境下基本可以将Sending + Waiting视为总的前端上传时间,服务器端真实处理时间基本在ms级别。

3G

方案 50K 100K 300K
ZIP 48273 85866 -
NOZIP1 66510 102841 -
NOZIP3 56889 85837 -

技术图片

与2G类型,3G网络环境下,ZIP方案依旧在批量小图片的上传中保持一定的优势,包括多请求并发方案。但是一旦图片大小达到100K左右就不再具有优势。

WIFI

方案 50K 100K 300K
ZIP 2091 2663 5821
NOZIP1 1499 1871 4271
NOZIP3 641 1418 3061

技术图片

WIFI环境下ZIP不具备优势,相反,当文件增大时打包时间的比例会很大,因此整体速度反而变慢。

结论

  • ZIP方案适用于网络速度较低(例如2G/3G)以及文件较小(小于100K)时的批量上传场景;
  • 2G/3G环境下并发请求仍然能获得比较大的上传优势;(在2G/3G环境下可以结合ZIP以及并发请求来进一步提供上传速度)

by 百度FEX

文件批量上传ZIP方案调研

标签:环境   ajax   前端   一个   for   and   img   维度   sock   

原文地址:https://www.cnblogs.com/jlfw/p/12986933.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!