There is wonder question: how does number of deployed portlets affect on performance of Liferay?
If I have deployed 50 war projects (summary about 80 portlets), can it be cause of very slow performance?
Or will it only insignificantly affect on performance of Liferay?
The Number of deployed projects, extracted in tomcat/webapps, will affect dramatically your server startup time for sure.
Depending on the portlet scope and tasks they might add an overhead to your browsing performance, but I don't think it's a big deal as long as you don't have lots of them rendering in the same page.
Now, things are a lot harder in a development machine (the tomcat server is controlled by Eclipse and you have portlets auto-deploying in that server each time you compile or change them). A portlet's auto deployment can cause all the other webapps to deploy too. Also, in development mode, you might experience permGen errors quite regularly, and in this case, since you're gonna have to restart the server each time, the huge startup time can become a major pain.
If you're in a development environment , you should really consider removing the webapps that are not beeing tested or needed.
Related
I have a large project with large set of micro-services. When I am working locally my computer barely handles running all of them plus IDE, MySQL and Mongo. This inconvenience is blocking me to add more micro-services.
Is there a known practice to work in this kind of environment?
While developing Java EE applications, the NetBeans IDE (currently using 8.0.2 but the issue is not restricted/limited to this version only) issues a low memory message quite frequently.
For example, while modifying and saving some Java classes (especially, JPA entity classes), the memory soon gets over-flooded after repeating this modifying and saving process for merely 10 to 15 entity classes. The IDE issues a low memory message disturbing the whole system severely.
It leaves only one alternative which is to restart the system and I indeed have been wasting more time in restarting the system than actually developing Java EE applications for couple of years :). I have not yet seen anything about this issue over the internet.
The auto-deploy (Deploy on save) option on the IDE is turned off forever. I never use this facility as it causes the heap/PermGen space to get over-flooded quite soon.
This may or may not happen in small toy applications. I am only talking about Java EE applications using a Java EE compliant application server.
I see if there is no way to get around this problem, then this IDE cannot be used in developing real Java EE applications because dealing with this problem basically takes more time than the actual development time and otherwise, the solution may be to lean towards other IDEs like Eclipse, IntelliJ Idea, JDeveloper etc, if they go better.
I am currently using,
GlassFish Server 4.1/Java EE 7
JDK 8u45
NetBeans 8.0.2
Is there a solution somewhere in the world?
NetBeans tends to be slower than other IDEs on Windows but this is far beyond the single term slow.
The picture is taken from a simple test web application (thus not an enterprise application). In enterprise applications, changing a single character in a single entity class is not affordable. One is likely to run into a big problem, if attempted. Fixing those errors shown in the link may take hours or probably the whole day or so.
Not to mention again that I am not talking anything other than large scale applications involving Java EE or other platforms like Spring.
Long story short : Nothing can prevent me from wondering as to how it is affordable to use this IDE in software industries. It is no longer usable in this way (Nothing to abuse. Honestly, I kept patience for almost three years. I am merely wasting time using this IDE).
We are using Grails 2.2.4, WebSphere 8.0.0.5 all running on AIX 6.1.0.0. Websphere is using the IBM JDK:
Java(TM) SE Runtime Environment (build pap6460_26sr3ifix-20121005_02(SR3+IV27268+IV27928+IV28217+IV25699))
IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 20120919_122629 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR3_iFix_1_20120919_1316_B122629
JIT - r11.b01_20120808_24925ifx1
GC - R26_Java626_SR3_iFix_1_20120919_1316_B122629 J9CL - 20120919_122629)
JCL - 20120713_01
The problem is that using:
grails.gsp.enable.reload = true
grails.gsp.view.dir="/path/to/gsp/views"
is slow, and by that I mean a good 20 seconds to render a small GSP. What's interesting is that in our local development environments it takes 2 seconds.
We've isolated this problem by having a controller that does nothing except call render(..) on a blank GSP with nothing in the model, so I can only assume it's the compilation but I could be wrong.
Has anyone come across other instances where rendering GSPs is extremely slow, or have any suggestions, perhaps it's some sort of weird JDK issue on AIX?
In addition to the bounty, whoever answers this correctly gets free waffles.
EDIT Just noticed this the other day: there are three environments with the same WAS config and setup and one of them works fine, so it is definitely some sort of environment issue.
I agree with your suspicion that it's compilation time. Perhaps you grails.gsp.view.dir is slow - a networked file system perhaps?
The real answer, unfortunately, is to not enable GSP reload in production.
It's clearly meant as a development convenience, and is not intended to perform well in production.
Make sure sitemesh is being preprocessed
grails.views.gsp.sitemesh.preprocess=true
Also I suspect this to be locking issue rather than compiling issue.
To at least reduce this problem set the following configs
grails.gsp.reload.interval= time in milliseconds.
something high depending on your comfort. Perhaps every hour?
If your file is changing the last modified time too quickly you need to lower the granularity by
grails.gsp.reload.granularity= Time in milliseconds.
Limit the number of classes being reloaded by
grails.reload.excludes
and
grails.reload.includes
Also remember the view path MUST end in slash. I didn't see that in the example you provided.
While I can't tell you what is the cause for your problem, I can point you to a tool that could help you look into the performance problem.
The Grails Miniprofiler plugin is a fantastic tool for examining end to end performance, all the way to the view (which is where you believe your problem is).
On some GSPs on a project of mine, I was surprised to see how heavy some views got with respect to the SQL calls (via lazy loading).
You may have suspicions for where the problems lie, and maybe you're hitting an obscure bug on that specific platform, but having hard numbers to point to bottlenecks is extremely useful.
For what it's worth, I haven't seen the problem you've described in any of my OS/environments. But I do remember experiencing serious pain with trying to deploy to JBoss 6.1 (since resolved) so I am sensitive to the idea that Grails could have issues on some environments.
Best of luck...
Grails Miniprofiler plugin
We are having the same problem on our application that tried to render a Birt report on Gsp page(it takes some times 5 minutes on prod server,We used Tomcat and Mysql) , not answer but a suggestion you might need to use the grails cache plugin ,that has a capability of cache gsp pages based on you requirement.
grails.org/plugin/cache
Turned out the problem was https://plugins.grails.org/plugin/sergiomichels/grails-melody-plugin. Who knew!
I use Seam3 + maven + jboss7 combination in my development. Would it be possible to optimize the loadup time when I do
mvn clean package jboss-as:redeploy
Currently this takes over 20 seconds with core2duo with an SSD (Mac Air).
In my workflow, it's common to make a lot of small changes and then redeploy and see changes. It's quite a big bottleneck with current setup, and it breaks my flow.
Would it be possible to do proper hot-deployment over my configuration?
Is there parameters for making startup faster when developing?
There is no hot-deployment. I'm not sure why it would be taking 20 seconds either. I get around a 3 second start-up time with JBoss AS7 and my deployment times are around 1 second maven deployments.
Is the server running locally or on a different machine? It could be the time it takes over the network.
You can write custom deployment scripts or write custom Java code to deploy applications as well.
I found about JRebel. It's a gift that I would not have expected to fall upon me. This supports my workflow and makes me much more efficient. If you need hot-deployment, try it out!
We deploy and debug a Jboss Seam 2.0 EAR app from within eclipse, booting it on Jboss AS 4.2.2. Right now we need to reboot it every time we change the message bundle, pages.xml, components.xml, or the model, which takes up to 45 seconds.
Is it possible to include aforementioned files in hot deployment, and what are the options for boosting boot speeds?
For a frame of reference, we work on Intel quad core 6600's or better, with at least 4GB of ram.
Edit: I'm looking for ways to improve both boot speed (thats the 45 seconds) besides hot deploying message bundle, pages.xml, components.xml etc.
This has been an outstanding issue for Seam for ages now : https://jira.jboss.org/jira/browse/EJBTHREE-1096
It's not a trick - more a method of working - but I have all of my UI code (page handlers etc) as POJOs so that they can be easily hot-deployed. Any more serious business logic I put in SLSB/SFSB and unit test them thoroughly so hopefully I have fewer deploys when testing the application via the UI.
Currently pages.xml can be hot deployed. I've read some solutions for reloading the message bundle but it's never bothered me enough to warrant further investigation.
When you say 'reboot' it sounds like you mean 'shut-down and re-start JBoss'.
You only have to force JBoss to reload the application, by touching the file (for an EAR or WAR archive) or the deployment descriptor (app.ear/META-INF/application.xml or app.war/WEB-INF/web.xml) for an exploded archive.
Reloading the Seam application EAR takes about 15 seconds on my machine, while starting JBoss takes about 30 seconds excluding shut-down but including starting the Seam application.
If you do want to restart JBoss, you can probably make it start faster by removing components you do not need in your development environment, such as JBossHA (high availability and clustering).
Since using JRebel with JBoss I have saved a lot of time.
http://www.zeroturnaround.com/jrebel/
It is not free but imho it is one of the tools that is worth the money and saves a lot of time restarting, redeploying an app after only a small change.
E.g. it reloads messages.properties.
What is it doing during those 45 seconds? If it is loading data from the hard drive then you could invest in a faster one. Non-SSD Hard drives are still a bottleneck these days. Although the time points out to some other issue...
I think it is best for you to open (or look for) an issue at:
https://jira.jboss.org/jira/browse/JBSEAM
(Note: For posting issues you need to login first.)
I've sped up boot time by moving to a war and stripping Jboss to a bare minimum (Since I'm only using seam POJOs and not EJBs).