Grails生成war包过大的问题

26 12月

最近在用Grails,确实体验了一把快速开发的乐趣。

Grails从名字上看就有点Rails的感觉,使用的很多细节也是。

快速创建项目,完整的测试框架,完善的插件体系,大部分东西都能够快速实现。

完成开发以后生成war包,部署到容器上就行了。

因为要把项目放到生产环境了,看了一下war包的大小,居然有40M+。

为什么包这么大

一个war包如此之大,确实惊悚了。因为项目本身并没有太多东西,实在不应该这么大。

直接拆开war包,主要的集中在assets目录和WEB-INF目录。

前者是资源目录,包括css,js和png等等。后者主要包含了lib。

前者的问题好解决,因为用了bower,所以下载的目录中有很多不是必须的东西。

而后者问题就比较麻烦了。Grails很方便了,集成了很多东西,比如GORM作为数据持久层上依赖了Hibernate,光lib的大小就是5M。

而且还有一些包明显不应该打在包里面,比如tomcat-embed.jar。

加快发布

自己机器上开发当然没有问题,大就大呗,但是这么大一个war包放在服务器上就有点吓人了。

首先是发布上的问题,这么大的一个包,远程部署过去实在耽误时间。

对于第一个asserts目录,直接在打包时exclude不需要的东西就是了,也节约不了多少东西。

对于第二个WEB-INF目录,可以操作的地方就多了。首先移除不需要的东西,可以节约10M左右。这样打包下来还是有30M左右。

首先在Config.groovy中配置


移除不需要的东西,可以节约10M左右。这样打包下来还是有30M左右。

对于那些不能移除的,比如hibernate,spring等等,直接放到容器的lib目录中。不随war一起了。

直接运行命令


这样的体积只有6M左右。

Proguard瘦身

即使是必须的lib,其中也必然有不少是我们不需要的东西,比如Guava,我常用的其实就那么几个类,其他的不需要。

这个时候使用Proguard的效果就格外好了。

具体的操作是一样的,虽然使用了Grails和Groovy,但是最后得到的还是标准的war包和字节码。

我推荐的是Hibernate和Spring的混淆参考现有方案,这两块实在太容易出问题了,而且收获也不大。

其他的工具库就可以放手干了。

瘦身以后体积为18m(包含lib目录)。

war包大的问题

war包的大小会在一定程度上影响性能,但是不得不说这个影响很小。

如果你的JVM不能完整的加在整个包,那么确实会有一些问题。

另外实际的系统可用内存也是一个问题。

特别是对于我而言,云服务器的资源是算钱,大量的无意义的大包会吃掉很多资源。

参考资料

Does the size of a jar file affect the performance of the JVM

发表评论

电子邮件地址不会被公开。