Here is a list of what you should not be doing in Liferay – Part 1 and also what you should be doing written right next to it in place of the wrong things:
- Write JDBC calls in portlets. Avoid JDBC calls in portlets. Please explore expando, service builder, dynamic queries and such from Liferay.
- Run elasticsearch & database in embedded mode in production. This is to be avoided always. For production and especially clustering, use remote elasticsearch and separate database.
- Use simple filestore for large number of documents. Right from the start prefer using advanced filestore.
- Forget to switch off developer settings in portal-ext.properties and verbose level of tracing in logs. Please switch off developer settings and verbose level tracing in logs.
- No performance testing and tuning of system before go-live. Please perform performance testing and tuning including GC / JVM / Caching / etc. for Liferay. Install Glowroot right from the start if possible in central pattern.
- Not configure security for various parts of the system. Configure SSL, xpack security for search. Explore the security page on Liferay Learn for various configurations. Perform VAPT at the start.
- Not enabling SSO. If SSO will be required in future, please enable it right from the start so that there are no user problems later. Also, it helps to reduce load on Liferay CPU of encryption.
- Not refer official documentation. Please refer liferay.dev – forums, blogs, learn.liferay.com, help.liferay.com, help center articles, Liferay Learn YouTube channel and more from the start.
- Not explore commerce, objects, publications, headless APIs, blueprints, asset library, fragments and such features. Please explore all this right from the start.
- Not explore benchmarking, performance, compatibility matrix whitepapers. Please explore them before go-live. There are lot of resources under resources section on Liferay.com including case studies, whitepapers and more.
- Not create go-live, integration, deployment diagram, architecture and such documents at the start. Please create go-live, integration, deployment, architecture, design documents from the start.
- Check Glowroot only when you face a problem. Instead, check your Glowroot regularly on weekly basis at least.
- Not size the infrastructure requirements for NAS/SAN for filestore and DR strategy. Please plan your infrastructure requirements in terms of NAS/SAN, servers for Liferay, database, elastic and others like web server before go-live.
- Not doing regular maintenance. Routinely do maintenance of Liferay, database, Elasticsearch, webserver and more by checking logs, JVM, CPU/memory usage, configurations and more.
- Not checking your lighthouse score incase of public websites. Regularly optimize your lighthouse score incase of public facing websites.
- Not have a DevSecOps strategy in place. Please create a CICD pipeline, DevSecOps strategy and implementation with Git style repository to manage things properly.
- Not have an upgrade plan mapped to quarterly release of Liferay. Please have an upgrade plan mapped to quarterly releases of Liferay.
Email me: Neil@HarwaniSystems.in
Following up on the Performance tuning in Liferay – Part 1 post – here are some additional points for performance tuning:
- The blue circle in Glowroot slow traces indicates that the transaction is still ongoing whereas yellow indicates it’s completed. Red indicates there is an error.
- You can change the JVM gauges as needed to see lot of different types of details of JVM
- You can use instrumentation from configuration using type ahead drop down (AJAX style)
- You can allocate specific cores to a JVM if need be using an argument on core allotment
- You can see thread profiles and take heap dumps from Glowroot itself
- Glowroot has sections on errors, queries and service calls
- You can get Glowroot to sustain it’s data through restarts using arguments
- For frequent garbage collection, check if some queries, etc. are continuously filling up memory and any fine tuning on caching can help
- It helps to follow these sections in no particular order and check them regularly: JVM – guages, MBeans (You can search your cache related things here – it’s like seeing things in VisualVM), threads and more, transactions, slow traces (all three areas throughput/etc.), thread profiles (search “blocked” here), queries, service calls, errors, sorting options in transactions, instrumentation, etc.
- Latest Glowroot works with Java 11 that is compatible with Liferay for customizations and product usage but not source code compile. This latest Glowroot gives lot many more options especially in transactions.
- If you are using Java 8, check if your Glowroot version is compatible with it. Typically 0.13.6 and below are compatible with Java 8 as far as I know.
Email me: Neil@HarwaniSystems.in
Expanding on my post here on performance tuning: Post | Feed | LinkedIn
Below are the main points to work on for a performance tuning engagement in Liferay – Part 1.
- Firstly, we need to find out what is slow: Database, service calls, elastic search, memory is an issue, threads are blocked / waiting, how much memory is a module taking, logs are printing what, etc.
- Check your configurations as per this post: How to debug Liferay? – Some pointers – Part 1 | LinkedIn
- Install Glowroot if possible, in central pattern and check following sections in it: slow traces, errors, service calls, threads, heap, instrumentation, configurations and so on for the problem timeframe.
- You can enable tracing in logs & Glowroot instrumentation on targets. You can also use plugins by Fabian Bouché like for fragment analysis or follow his blogs on www.liferay.dev/blogs for using Glowroot in upgrades.
- The above will give you hints on what is slow. Especially open the FLAME graphs and threads along with heap dumps to analyze which threads are blocked or waiting, how much memory is allocated to what in slow traces of modules and so on.
- Then run a load test in simulated environment after checking compatibility matrix to get latest statistics for various scenarios like web content on portlet or in fragment, API calls, integrations, heavy load on Elasticsearch and so on with experimentation on themes.
- After getting the slow threads and details in flame graphs plus slow traces, if it’s custom code or configuration or DB call or ES which is slow, optimize it like Hikari pool connections or if it’s source code of Liferay, open the GITHUB repo for Liferay portal, check the source code and reach out of Customer Success / Global Services / Support with inferences depending on your engagement in account. Your Customer Success Manager or Sales can guide you on this.
- GS / CS will work internally in Liferay to get you the best options and / or patches in case they already exist. Many a times this could also have been fixed in a Hot fix or Fix Pack already. Alternatively, configurations could also solve such problems many a times. To check these go to Liferay customer portal and check the changelog for fix packs. You can also refer to Liferay Learn and Help Center for help articles and tutorials.
- Various areas of performance tuning: Database, HTTP calls, App server, ElasticSearch, Threads, Heap optimization, Caching and more. We will follow up this post with more pointers on performance tuning in Part – 2. A good list of areas is to check in the deployment guide for your version.
- Thanks to Fabian Bouché David Nebinger and many more at Liferay Global Services / Support / Customer Success and Customer Support / Engineering due to which I am able to compile the above. Above is a compilation of work from many sources internally in Liferay via work with customers & externally which hopefully should help many of Liferay customers and partners. This also serves as a case study on performance tuning.
- Email me: Neil@HarwaniSystems.in
Ideas on Innovation around Software. We Thrive On Ideas. We are Learner Centered, Open Source & Digital Focused.