一个小程序的性能优化,从5小时到170秒的改进-即速应用

一个小程序的性能优化,从5小时到170秒的改进

浏览量：2898 时间：2020-01-11 来源：weixin_34216036

昨天帮同事优化了一个小程序,程序的功能很简单,将每天产生的若干压缩包解压读取清单文件入库,并根据清单文件的情况选择包内的文件对数据库进行字段更新,每条记录被更新的2个字段分别存储在2个文件中,文件都是小文件,90%以上小于2K.压缩文件有1600左右，解压之后文件数量在82W个。一般处理的思路就是将文件解压，然后读取清单，与数据库比较去重，入库，更新，删除文件，这些功能都可以在多线程下完成。逻辑思路就是这样，但是对于性能的影响主要在程序设计中对于文件的处理上。82W个文件多线程解压至少要25min，问什么这么慢呢？其主要原因并不是在CPU上，IO设计上是关键。计算机的存储主要是用来持久数据的，根据持久的时间、访问的模式来看，主要就是HDD、RAM、CPU Cache.我们的这个应用文件IO主要是拼IOPS。我没有SSD，所以这个指标也不太高，那就只能考虑RAM了。如果处理文件的尺寸比较大，除了HDD我们肯定是没有办法，但是如果文件的尺寸很小内存就是一个很不错的选择。由于我的业务只需要读取到压缩文件的内容，对于文件是否解压实不关心的(解开最后也会删除)，最佳方式是在内存里面进行解压操作，内存的IOPS比HDD高出若干数量级，只要控制好线程和内存的使用就可以了。处理压缩文件可以先读取文件中的文件列表，找出需要的文件进行解压，这样也能减少IO次数。 .net 4.0里面的并行类可以很方便的给我们提供多线程操作的功能，用起来也很方便。

即速应用倡导尊重与保护知识产权。如发现本站文章存在版权问题，烦请提供版权疑问、身份证明、版权证明、联系方式等发邮件至197452366@qq.com ，我们将及时处理。本站文章仅作分享交流用途，作者观点不等同于即速应用观点。用户与作者的任何交易与本站无关，请知悉。