|
|
5 回复 | 直到 11 年前
|
1
10
不幸的是,我不确定除了你已经做过的事情,还有太多的事情要做。正如您所知,当它启动时,会发生很多事情,包括所有的插件解析/加载、向域对象添加动态方法以及groovy的整体动态特性。 我不确定您使用的是哪个版本,但我要求您在1.2中启动时关闭依赖性检查,因为这也会给启动时间增加很多时间。 我意识到上面的内容没有太大的帮助,所以这可能是:我将应用程序拆分为几个插件。一个用于域对象,一个用于绘图功能,一个用于Excel导入,另一个用于我需要的一些UI构造。我之所以这样做,并不是因为启动时间太慢,而是因为我可以在将所有东西集成到一起之前分别测试系统的各个部分。 我将要添加一个新的功能,其中至少涉及10个新的域对象,我首先在一个单独的插件中开发它们,为它们必须从核心应用程序与之交互的少数对象提供存根。这样既可以减少启动时间,又可以更好地隔离代码。 所以如果这是你的一个选择,试着把事情分开,这样你就可以单独处理它们,这将在一定程度上缓解你的问题。在让您的团队分别处理较小的组件、更好的模块化等方面,还有其他好处。 希望这是有帮助的。 |
|
|
2
3
170个域类相当大,但是2分钟对我来说仍然很长。你安装了很多插件吗?可能是调试设置过于冗长? 我很好奇,如果你创建了一个新的Grails应用程序,复制了你所有的域对象(以及域对象可能需要实际操作的插件的子集),然后看看需要多长时间才能开始。 如果可能的话,琼提出的把事情分开的建议是一个很好的建议。我在以前的项目中做过类似的事情,我们有一个域插件,我们的其他应用都依赖于那个域插件。 您也可以使用 grails events 在启动时记录一些时间信息,看看瓶颈在哪里。“plugininstalled”事件的计时应该是很好的,因为我认为除了其他插件之外,Hibernate插件也会被它捕获。 |
|
|
3
2
您可能有依赖性问题。如果您使用的插件依赖于Maven中具有“开放式”依赖关系的库,那么Grails每次都会查看该范围内是否有要下载的更新版本。我不知道为什么会有人这样指定它。这似乎会导致不可靠的行为。对我来说,罪魁祸首是亚马逊的Java AWS库,它自然地被一个与亚马逊云对话的插件所使用。 http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10 注意它的一些依赖项是如何这样的 org.apache.httpcomponents httpclient(4.1、5.0) 看起来每次Grails都在寻找一个更新的版本(如果有下载的话,我刚刚注意到在这次运行时httpclient的4.2-alpha1会下降)。 通过从插件中删除该依赖项并手动将所需的库添加到我的.lib文件夹,我将启动时间从>30秒缩短为<1秒。 |
|
|
4
1
你可能想看看是否还有其他的旋钮,你可以转动除了颗粒,以解决这个问题。 您是否尝试将此作为性能问题处理?你可以看看盒子的性能,试着找出瓶颈是什么。是CPU吗?这是磁盘读取问题吗?你能在虚拟机上附加一个分析器,找出你大部分的启动时间都在消耗什么吗? |
|
|
5
0
您是否尝试过像这样的基础知识,以便进一步部署到您选择的servlet容器中,或者在适当的位置进行部署。
|
推荐文章