Many times an incorrect process is used to set up the production application server for Liferay:

  1. Download a Liferay bundle.
  2. Expand on the server.
  3. Start up and go.

We cannot emphasize how wrong, wrong, wrong this is. Best practices for a production Liferay setup mandates using a manual app server configuration and deployment process.

The Liferay bundles are great for demonstration purposes – expand them and you can start up Liferay with little or no configuration. You can quickly kick the tires and take it for a test drive.  Bundles are also great for developer workstations because their focus is on development activities.

But bundles are not, I repeat, not to be used for production setups.  Here’s a short list of reasons why:

  • The application server in the bundle is typically out of date, usually very out of date.
  • The application server is not tuned for production.
  • The application server is not configured for security.
  • The application server does not include native (performance enhancing) add-ons.

None of those reasons really matter on a developer workstation or in a demo environment, but for your production system(s) these reasons are critical.

Some will argue that while these reasons are important for production and agree to a manual installation for that environment, they do not apply to the test, QA and/or other non-production environments.  We would argue that a primary purpose of these non-production environments is to simulate the production environment in every aspect, to verify that deployment procedures and the deployed artifacts will work correctly when they get to production. You can’t verify this if the test environments are running bundles.

So what is the process for setting up Liferay application servers for production?

The best recommendation is to have your operations folks do what they normally will do to set up a new application server.  They likely have a standard process to install an approved version of an application server, along with configuration guidelines for performance and security.  Let them do what they would normally do, then deploy the Liferay war (and dependencies) into that container.

If you don’t have an operations team or you don’t have standardized processes, it’s time to define some 😉

First you need to pick an application container.  You can choose either a lightweight application container like Tomcat or a heavyweight JEE container like jBoss.  Enterprises will typically go for a JEE container because they need service contracts for their software, but Xtivia actually recommends using Tomcat for Liferay installs, Liferay does not need or use any JEE functionality, plus there is a ton of free online documentation and support to keep your Tomcat running.

Regardless of your application container selection, ideally you’re going to want to use the latest stable version available.  This version will have all of the latest bug fixes, security enhancements and performance tweaks.

Install the application container per the recommended instructions, but your work doesn’t end there.  Research online to find the ideal configuration for security and performance tuning.  Consider, for example:

  • Set up the application container logging to reduce to minimal log generation
  • Set parameters to maximize the use of available system memory
  • Eliminate server connectors that will not be used (e.g., if using Apache HTTPd fronting Tomcat through AJP, disable the HTTP and HTTPS connectors)
  • Remove any pre-installed applications (e.g., the Tomcat Manager application) that will not be used
  • Install any native libraries that will help performance (i.e. the Tomcat Native library)
  • Etc.

Some optimizations and configuration will be very environment-specific and generic guidelines won’t apply.  For example, in the Tomcat configuration for a connector you can set how many connections are accepted at a time and the timeout period. These settings should be set accordubg to your expectation of load on the Tomcat instance, balanced against available system resources.  Often the default settings will work fine in limited testing but may suffer or break under load.

When your application server is ready, it’s time to deploy the Liferay app.  Liferay’s documentation for installing to an existing application container can be found here. (The link is for 6.2, but similar documentation is available for earlier versions of CE. The documentation applies equally well to EE.)  Reading the documentation is actually quite important; Tomcat, for example, covers updating Mojarra so JSF portlets will work. Even if you’re not currently doing JSF, you might want to do this anyway since you never know what the future holds.  Each application server page will address configuration changes that should be applied to the application container; you want to make sure you implement the suggestions or actively discard the recommendations, but do not simply ignore them.

If your application container is not covered in the documentation or you’re unsure about all of the changes listed, one trick I’ve used was to download a bundle and the corresponding “clean” application at the exact same version.  For example, the Liferay 6.2 Tomcat bundle ships with Tomcat 7.0.42. If you download a clean 7.0.42 and then use a tool like BeyondCompare, you can see all of the changes that were made in the Tomcat bundle and can replicate those changes in the new version.

So now your application container is set up and Liferay is deployed – you’re done, right?  Well no, not actually.  Just like you have a process to keep Liferay up to date, you should also define a process to keep your application container up to date (at least for the dot releases).  The application containers get new releases with bug fixes, performance and security enhancements that you should include in your production environment.

Additionally you should be using ongoing monitoring of your application container.  Over time the assumptions you made during initial setup may be validated or disproved, or the underlying circumstances may change.  If you’re not actively monitoring your application container, you will have little if any warning of a pending disaster.

Note that this process will give you a solid application server, but that’s not all there is to an optimal Liferay environment.  Ideally you’ll have an appropriately sized cluster, a front web server handling SSL termination and static file handling, a caching appliance returning cached resources, offloaded indexing/searching (i.e. SOLR), etc.

Feeling overwhelmed by all of this?  Xtivia’s Liferay Configuration and Performance Review (Liferay-CPR) will bring our team of experts in to your environment to analyze your environment and make appropriate recommendations. Just contact us to get the process started.

Share This