Thursday, October 09, 2014

Alfresco Startup time

As some of you may know, Alfresco is an EDMS that runs on tomcat (or other java container) in linux or windows.

I've been working with Alfresco for several years in various capacity, and anyone who works with Alfresco Community Edition (CE) knows that configuration changes require restart, and the restart is painfully 5 minutes slow.

Although some of the 'obvious' fixes are to move alfresco.war and share.war to independent tomcats, and only restart the one that you need, that is still configuration/integration/new possible issue point (particularly if you are doing low-volume sites and want to use only one tomcat/server).

The 'performance' is always relative to the hardware you are using, and some the time will vary depending on big cpu/slow disk, low-end cpu/high-end disk, etc.  As such, will simply provide a baseline which is Alfresco 4.2.f, the bitnami linux installer on fedora.

All of these tests are with a baseline alfresco install, no content, no indexing.

Relative startup time Configuration Notes
0% (baseline) -XX:+UseG1GC -XX:MaxPermSize=256M -Xms1024M -Xmx1024 Bitnami base setup, 1024M heap.
-59% (slower, minutes dep. on hardware) -XX:+UseG1GC -XX:MaxPermSize=256M -Xms256M -Xmx256M Comparison when trying low memory (256M), how much of a difference it makes.
+0-5% (trivial) -XX:+UseG1GC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M Excess ram (for startup) does not impact startup time. Note however you usually should have 2G-8G for normal, real-world, usage
+12% faster (20 sec dep. on hardware) -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M Changing to a Concurrent GC (because we know CPU is maxed) actually made a good difference (assuming you are not heavily disk IO bound).
+14% faster -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M
put tomcat/alfresco/openoffice in a ramdrive to remove disk IO concerns (/dev/shm for example)
Keeping to the most performing setup, try ramdrive to challenge disk IO issues...really aren't an issue in startup. However...your alf_data location absolute has an impact on real-world content.
+8% faster (slower than ConGC with defaults) -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 Additional GC tuning (out of quick/ignorant, didn't want to spend a lot of time on this). Just used what was from Http://
+18% faster -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M
Modify /alfresco/WEB-INF/web.xml and /share/WEB-INF/web.xml with metadata-complete=true and absolute-ordering
Most performant memory setup, then added this find: Obviously not a solution if using stock or as-is installer approach, but if you can customize your WAR (not just the exploded directory) surprising gains.
+20% faster (memory change, small app conf change, ramdrive) -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxPermSize=256M -Xms2048M -Xmx2048M
Modify /alfresco/WEB-INF/web.xml and /share/WEB-INF/web.xml with metadata-complete=true and absolute-ordering, ramdrive tomcat/alfresco/openoffice
putting it all together, the 'quickest' fast startup option if you have the ram for it, but disk io isn't an issue with startup.
So, some quick wins for decent return depending how much you want to modify your install. However, at the end of the day the startup is CPU (single-thread) bound. Now, some of you may remember the older Jboss application servers (4-6 series) and how they were getting slower and slower on startup, then they re-engineered there startup process for *controlled* parallel startup of services. That may be what is really needed to get the Alfresco CE startup time down.

Recommend the second to the last - setting up a ramdrive for that little of a gain is not worth it, and if you are really trying to push startup times, then get your alfresco and share on different tomcat instances first before moving to ramdrive.