ajax大参数（大数据）提交性能分析

近期在项目中发现如下一个问题

项目中有个提交现场事件的功能，该功能主要是在web客户端保存现场数据（主要有截屏，终端日志等信息）然后提交到服务器上方便我们分析定位问题。客户在使用该功能的过程中反应点击提交后反应很慢，大概要等10到20秒的时间浏览器才能操作，期间页面不响应事件。

根据客户描述分析了下的代码流程，很简单，主要通过OCX控件截屏，在将前端的日志等文件使用OCX控件打包，在将之转换为base64码，最后当然是使用ajax异步进行提交（使用prototype框架ajax方法）了。验证过程也很简单主要是各个认为有性能缺陷的点都插入了时间点日志，并且使用了各种型号的zip包（主要验证数据量大对报文提交的影响）进行提交。

分析后发现OCX截屏用时最短，ocx打包和转换base64码根据zip包的大小，也就是说zip包越大耗时越长（一般在1-3秒之间，5秒基本是50，60M的数据了)，最后发现用时最长的居然是prototype的提交（排除服务器响应时间，即是说收到请求处理后的时间可忽略不计，tip已验证过基本在毫秒级），prototype的ajax方法提交居然用了10多秒钟（本次测试最大zip包的时间）。当然肯定要跟踪下该ajax方法哪里损耗时间了，最后一通跟踪，发现prototype方法的ajax提交会对请求参数进行处理进行各种转换操作，prototype的toQueryParams方法对输入参数执行了decodeURIComponent方法，在调用prototype的ajax方法时，已经对参数串执行了encodeURIComponent方法，后续prototype对参数串转换为键值对映射时又执行了解码操作，因为涉及的解码字符串比较大，js脚本一直处于执行中因此导致后面浏览器进入处理假死状态。

后面解决的办法也很简单，自己重新写了一个原生的ajax请求方法，不在对参数进行处理，调整修改后测试验证了下，时间一下少了4分之三，基本本次测试的最大包提交也在3,4秒之间，本次分析就差不多结束了。