Servlet filters:

By default, Liferay has a few enabled and running servlet filters. Servlet filters are Java-based pluggable components that process, and intercept requests sent to servlets. They are also responsible for responding before the container responds to the client after the server code is completed.

Since there are many service filters present in Liferay, your business may or may not require all of them to remain active at all times. It’s like disabling a few unrequired ones to increase the system’s performance. You can simply disable the unwanted server filters by using the

portal-ext.properties file.

Just copy the servlet filters from the base (original) portal.properties file and put them into the customized file. After that, go through the lists and see which ones you can disable. You can set them to false to disable them.

Performance properties:

These are the default configurations present in the portal. properties that have been set to optimize the performance. It basically belongs to the properties file changes, which you may need to make once you’re in the production environment.

There are some merged CSS files in Liferay performance profiles that are set to false for easier debugging and site/application deployment. You need to set this property to true to load the programs faster and thus help more in performance tuning.

theme.css.fast.load=false

theme.css.fast.load=true

Furthermore, you need to set this property to true to load the combined JavaScript-based files from the javascript.files property and make them into one compacted file for faster loading and optimized performance tuning.

javascript.fast.load=false

javascript.fast.load=true

Caching:

Memory is one of the first things to look at when you think about optimizing performance. Caching is basically required for improving application scalability, which reduces database overhead due to object relational impedance. Municipal garbage and unwanted data extracts, if they occur in abundance, can disturb the performance and also reduce it.

There are three levels of cache, which are described here:

• L1: Chip Level Cache
• L2: System Memory
• L3: Swap Space

Garbage collection:

During the GC (garbage collection) process, all the processing in the JVM stops. It’s because it goes through every part of the heap, looking for unwanted or dead objects. Once they are found, it frees up the memory. It could not occur in the server environment as it could slow down the processing. Although there are some JVM switches that you can enable to reduce the process halt time during the GC, this is again a major part of the performance tuning process.

JVM Parameters:

A JVM is basically a detailed specification of what is required for JVM implementation. It decides when the unused variables will take up heap space and when it is time to clean them up. Over JVM, you just need to write the code once and run it everywhere. Also, you have a run-through of automatic memory management.

JVM is used to perform detailed heap tuning to appropriately optimize performance. It’s not just the max (maximum) and min (minimum) processes. You can’t just rely on the automatic GC tuning for the optimal cleaning of young and old generations (which come under GC). You can perform detailed heap tuning for GC’s young generation, survivor spaces, etc.

Some of the common JVM parameters are –

NewSize, MaxNewSize, +UseParNewGC, +UseConcMarkSweepGC, +CMSParallelRemarkEnabled, SurvivorRatio, ParallelGCThreads

Monitoring:

The monitoring section involves screens where all these above-written proceedings are captured and analyzed using adaptable performance tuning tools. The major ways of performing monitoring optimization are as follows:

• Monitoring: Visual VM, This is a tool that provides detailed information about Java applications while they run on the JVM, for troubleshooting and application profiling as well.
• Monitoring: Lambda Probe, you can use this tool to simultaneously monitor the old generation, perm generation, survivor space, code cache, Eden space for figuring out the memory usage, application details, data sources, deployment, logs, threads, etc.