Liferay 'build services' and deploys are too slow

Question

I'm using the Liferay platform to develop a company portal (version 6.1.1). This portal already have a considerable implementation and database size (174 tables).

As expected, from the beginning the build services and deploys were getting slower as the project were growing.

The problem is that with the current implementation it takes like 20 minutes to perform the 'build services' and about 3/4 minutes to perform a deploy which happens even if i change a simple string in the code. And for every 3 deploys it´s necessary to restart the server because it seems to froze.

My machine specs are:

• Intel core i5-3210M
• 8GB RAM
• 64bits

And this are the memory args of my liferay server:

• -Xms1024m -Xmx1024m -XX:PermSize=1024m -XX:MaxPermSize=1024m

As you know this waiting times have a huge drop of performance in the implementation.

My questions are: is this normal? If yes, what kind of alternatives do i have in a future portal implementation?

Thank you.

Answer 1

174 tables are quite a lot - more than Liferay itself brings. I'd recommend to spread out your application into separately deployable plugins - they don't (technically) need to be in the same plugin, service builder allows you to use the services across different plugins.

Proper dependency management should help you to isolate the functionality that you'll extract into separate applications. Declare which application needs which other application deployed before, and you can access the services cross-context.

To answer your comment-question, sampling with only two projects: Create them, both with service-builder. Let's call them common-portlet and app1-portlet. Obviously, app1-portlet uses components (and services) from common-portlet.

In app1-portlet, edit docroot/WEB-INF/liferay-plugin-package.properties and add the line

 required-deployment-contexts=common-portlet

This will make sure that app1-portlet is only deployed when common-portlet is available. Also, common-service.jar, the API of common-portlet, generated with service-biulder, will automatically be put on the classpath of app1-portlet, in other words, you can call the services that you implemented in common-portlet.

Assuming your more abstract portlets have a more stable interface (typically this indicates a proper architecture), changes to app1-portlet (or app2-portlet etc.) will only affect the portlet where you make a change in. Even if you have a change in common-portlet, service-builder will be relatively quick, however, on interface changes you still need to recompile everything, but that's the nature of dependencies. If you don't change your interfaces, you'll only need a redeploy.