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 slow....like 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://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.6|
|+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: http://wiki.apache.org/tomcat/HowTo/FasterStartUp 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.|
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.