After upgrading a grails application (usage of multiple inline plugins, > 130 controllers, > 140 services, > 180 domain classes, > 600 GSPs) from 2.5.4 to 3.2.8:
grails run-app before update: 2:10 minutes.
grails run-app after update: 5:50 minutes.
Most of the time the grails 3.2.8 run-app is hanging at ":boot-run". Especially after spring security core has initialized (about 2 minutes after start) it hangs for about 4 minutes. Additionally the CPU usage is very low compared to grails 2.5.4.
The test was repeated with different machines and faced similar results (Mac, Linux and Windows machines).
What can be the reasons for this behaviour?
That's incredible: If you restart intellij before running ´grails run-app´ for the very first time, the boot time is 2 minutes with grails 3.
Do not use the restart button in intellij 2017.1.1.
Update
There is definitely some memory leaks in runtime environment of IntelliJ.
Updating to Java 8 SDK improved situations a lot.
Adding "bootRun { jvmArgs = ["-Xmx4096m"] }" to build.gradle was key succes.
App starts now in 30 seconds. I would recommend to upgrade to grails 3.
Related
We have JUnit tests that boot up the entire server and then test some functions in the booted server. However this takes a lot longer than when simply booting the server regularly through it's main function, outside of a a junit test. Why could that be?
More concretely, we're using the dropwizard framework with a jetty server. The logs I get after starting within a unit test are
INFO [2022-09-19 15:12:45,985] org.eclipse.jetty.server.Server: Started #60649ms
and the logs I get with a regular application start are
INFO [2022-09-19 15:15:06,887] org.eclipse.jetty.server.Server: Started #13093ms
As you can see, it's around 6 times faster outside of JUnit.
Is there any reason for that? The server spawned in junit isn't 100% identical to the other one but it comes pretty close. I don't see any reason why it should just be that much slower. Is there any "known" reason why this is happening or is it more likely that's something about how we spawn the server in our testing environment?
When trying to find the bottleneck, I couldn't identify one single place that runs slower. It seems that everything is just running slower in the tests.
Edit:
An additional information is that I run on an M1 mac. My previous results, where the tests were 6 times slower than the server start, were with brew install --cask adoptopenjdk11. However when I switched to the brew install --cask zulu-jdk11, now the disparity is much smaller: 18 seconds for test runs, 12 seconds for server starts. It doesn't make the mystery smaller, but it makes me a bit happier.
We managed to migrate our system into Hybris 6.7
System update took around 5 hours
Was this due to the migration, or is this the expected duration after each deployment?
Could this be enhanced by any mean?
Thanks
I think it take once for first upgrade because of type system changes. Did you try and logging it in your pre-prod system? You can check steps elapsed times in logs/screens.
We have upgraded from TeamCity 8 to 9 and our .net builders increased their build time from 3 minutes to 15 minutes.
We started investigating this issue, by doing the next steps:
Enabled "Performance Montioring" build feature - and we saw the disk io is maximum 9% and cpu is maximum 40% (our build agents have 2 cores and 4gb of memory)
Enabled .net runner logs to see if something in msbuildbootstraper takes lots of time.
After 2 days of investigation (we checked our antivirus, io, cpu and memory and every looks fine) we started to suspect that MsbuildBootstrap of jetbrains takes most of the time.
We took one build, that with "msbuildbootstraper" takes 32 seconds and switched it to "Command Line" runner and called msbuild our selves and the build time decrease to 5 seconds.
We are currently thinking about downgrading to version 8 of teamcity or moving to tfs, before doing so - do you have any suggestions for fixing/throubleshooting this?
And we found the solution: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/206819485-JetBrains-BuildServer-MsBuild-Bootstrap-exe-9-0-9-9-0-14-hangs-for-30-seconds-on-TeamCity-9-0
As the link above says, add this configuration to MSBuildBootstraper:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
More info here: https://confluence.jetbrains.com/display/TCD9/Common+Problems#CommonProblems-Problemswith.Net-relatedTeamCityTools
I am having trouble deploying the app on to the worklight developerment server (Liberty profile).
Starting the eclipse from command line with -clean option did not help me. My configuration is
Eclipse Kepler SR2 Java EE - 32 bit version
Java 7 32 bit version
worklight plugin 6.1.0.01
Windows 7, 32G RAM, 512g SSD, core i7
I don't have any proxy network settings.
Whenever I select -> righ click -> Run As -> Run on WorkLight Development Server, the build process is taking very long time, approximately 30 mins. out of which almost entire time is spent at "Worklight application builder: (20%)
I'm almost certain that this happens because of the Java process.
My suggest to you is to kill the Java process running in your system followed by re-starting Eclipse. Then, try to start the server and repeat the Run As... steps.
I am using Ruby on Rails under windows, installed with railsinstaller. Everything works fine, except that any command such as rails console or bundle exec rake db:migrate takes on average 8 seconds before executing. (rails s and rails -v are exceptions and take about 1 to 2 sec to launch, which is still abnormally high). I am not talking about the time of the entire command, just the time between when I hit enter and when I see the first output.
During this time, one core of my processor is working at 100%, and there is no load on the hard drive. I really feel like that I am waiting for some kind of timeout to expire, because I don't see why rails console should take that much processing power (I have a Core 2 Duo processor).
Do you have experienced this kind of problem ? What can it be ? How can I investigate this ?
It is spinning up your Rails environment, not just loading an executable. It is not Windows specific. It takes about 10 seconds on my Core2 Duo iMac. I've seen similar delays on Linux boxes. Here is an article that gives some hints that may help.
rails-3-osx-speed-up-console-loading-time