多零已重构数据传输方式、算法

原创未经同意，请勿转载 2022-06-28 1347次阅读

多零程序猿在后台统计发现，存在大部分用户在使用导出条形码、标签、二维码功能过程中，耗时较长，例如500个默认设置的条形码，部分用户在批量生成导出中耗时就高达135秒，即2分多钟。

然而，多零程序猿在本地环境中测试耗时却少得多，批量生成导出耗时约20秒。

问题出现在哪里？

多零程序猿分析，问题不止一个，涉及到网络环境(带宽、运营商服务质量)、生成算法、数据传输方式、文件格式压缩、服务器存储方式等一系列问题。

然后多零就开始寻找解决方法，准备重构整个导出流程。重构之后性能可以提升多少？刚开始没底，但可以肯定性能会有提升，只要有提升就值得去做。前后花了将近20天，就最近一个多星期为了不影响白天用户的使用，多零程序猿每天通宵调试。

优化结果如何？

最终优化效果比较欣慰，批量导出500个条形码，耗时缩短至10秒，相对于此前的135秒，性能提升不少。(此过程不包括下载过程，下载过程受网络环境影响，应用端无法控制)

做了哪些优化？

彻底弃用此前的Http Post方式，改为WebSocket方式传输数据。基于WebSocket减少网络链接之外，也很容易控制发送数据包的容量大小，数据包太大，网络底层会频繁拆包，性能降低；数据包太小，则发送次数增加，产生不必要的消耗。最终调试结合服务器安全将应用层的数据包大小定为30K，服务器WebSocket最大接收32K。
文件压缩方式并没有太大修改，只是小改优化文件格式，在不同的环境自动使用不同的文件格式，最终得到的导出文件一样，但导出性能却提升了13%，而且文件容量大小普遍减少30%。
服务器端由磁盘存储改为内存存储，这些文件临时存储，并没有必要使用到硬盘，使用内存刚好适合。但此项性能提升只有3%，估计多零正在使用的云服务器硬盘是基于内存构造的。
实际上，做完以上3点工作后，性能提升只有约35%，性能大幅提升的是优选网络。原本多零使用DNS最近节点，实际使用发现就近节点的网络也并非是最快的，例如多零程序猿在广州，WebSocket测试深圳的集群节点耗时250毫秒，测试杭州的节点是120毫秒，服务器硬件、网络配置一样，但远在杭州的节点反而比最近的深圳节点快一倍！网络质量涉及太多因素，多零无法优化网络质量，但是可以为用户选择最优的网络。

后续优化

按照最开始的优化计划，还有一项是未完成的：增加集群节点。上面优化第4点说到，为用户选择最优的负载节点，但有可能对于部分用户，多零的全部节点都不是最优的。目前多零节点多在东南沿海，但对于西北、东北部用户来说，都不是最优节点。下半年多零计划再增加2个集群节点：四川节点、青岛节点，到时整体优化才算完成。

最后多零想说

多零已尽可能地发现问题，并解决问题，但是用户的使用环境多种多样，可能存在某些使用环境多零没有考虑到，而因此出现的问题多零难以发现。

如果您在使用过程中发现问题，或者有使用不爽、不方便的地方，请反馈给多零，提醒多零，多零就会为您提供越来越好的服务。

文章来源于多零条形码，未经同意，请勿转载。