性能调优实践总结

     上次和大家介绍了使用YUI者compressor框架进行自动压缩工作中遇到的问题和技巧.

     本次,继续压缩的话题,谈谈压缩过程中的优化.上次提到在对js/css文件进行压缩之前,需要做一步转码工作.需要使用java自带的native2ascii工具将GBK/utf8格式的文件内容转换成ascii统一编码---unicode编码格式(以\u开始),但是系统使用不久,就发现了一个严重的问题:性能瓶颈.在发布文件列表比较大时(>100),系统处理文件压缩的时间长1分钟+,这个数据是互联网用户无法接受的.所以对此发布过程亟待优化.下面分享一下优化过程(优化效果是tps大概提升了2~3倍)

     1.分析可能影响性能点

1.db读取js/css时间:js/css以blob字段存储在数据库中,大字段内容读取,网络传输会较慢

2.发布过程逻辑优化,整个发布过程因为有其他类型文件发布,所以有一些js.css发布不需要的操作

3.转码效率低

 4.yui 压缩性能差

     2.确定几个可以优化的关键路径点(影响性能比较大的)

1.发现db读取过程占用的时间占整个发布的时间 比例非常小(<2%),且如果要改大字段存储方案,代价高,优化效果不明显

2.有必要,比如一些xml解析操作会比较耗费时间

3.发现整个发布过程中,转码过程几乎占用了一半的时间,可以考虑其他方案

4.压缩也是占用资源,消耗性能比较大的,但是是外部jar包,想要优化比较困难

     3.寻找解决方案

            根据上述情况,认为可以优化的点在于转码过程.因为之前是使用调用本地java工具的方式进行转码,而这一操作其实是需要每次都要新建一个进程来执行这一的操作,这个过程导致进程上下文切换和调度非常频繁,所以非常耗费性能.

           其实对于js/css文件的转码最主要是对中文字符转码,而这是完全可以通过扫描字节流来实现转码工作的,所以写了一个转码java工具类执行转码,去掉native2ascii工具来完成,并对两种实现方案对比,发现前者只需要10%的时间就能完成相同的工作

     4.优化效果

     优化后的效果:tps提升为~3倍左右,500个文件只需要25s左右的时间就可以处理完