All Things WebSphere
Concerns and issues relating to all versions of WebSphere Application ServerTuesday, May 10, 2011
WebSphere Application Server - Performance considerations for deploying very large Java Enterprise Edition (JEE) applications
Please consider the following when developing and deploying very large applications (> 30,000 classes) bundled in one ear file.
The cost of having a large number of classes depends strongly on details of how the classes are present in the application, and whether Java EE5 features are enabled, and whether scanning is left enabled on all of the classes.
1) If the classes are exposed in a web module archive "WEB-INF/classes" directory, that will cause very large slowdowns. The converse is for the classes to be in a JAR, either in a simple utility JAR directly contained by the application archive (EAR file), or for the classes to be contained within an EJBJar, or for the classes to be contained in a JAR beneath a web module archive "WEB-INF/lib" directory.
2) If javaEE5 processing is enabled for the classes, either because the classes are present in a javaEE5 enabled EJBJar or WAR, that will cause large slowdowns. The converse is for the classes to be present in a location which will not be scanned, for example, if there is a "META-INF/application.xml" for the EAR, and if all of the modules use a pre-javaEE5 version, or if all of the modules are marked as metadata-complete.
3) Even if javaEE5 processing is enabled, if a large subset of the classes do not require annotation scanning, that can be disabled using special properties in the application and module "META-INF/MANIFEST.MF" manifest files.
4) If using WAS version 7, please upgrade to fixpack 7.0.0.13 or later. We put in some optimizations in 7.0.0.13 to make the reading and writing to disk of applications much more efficient. Large apps (like Commerce) that are over 100 MB in size deployed 30-40% faster.
5) Check if the application is EE5 (in the application.xml, look for the version= tag). If so, check if there are any WAR files inside the EAR that contain numerous JARs under WEB-INF/lib. If those are present they can increase deployment time significantly. There is a tuning option available to help, and it's documented here PK87053: JAVA ENTERPRISE EDITION VERSION 5 APPLICATIONS TAKE A LONG TIME TO DEPLOY http://www-01.ibm.com/support/docview.wss?uid=swg1PK87053
When deploying the application, there will be an unavoidable cost of copying the application files during deployment, which will be proportional to the total size of the classes (but not proportional to the number of classes, unless these are exposed in a WEB-INF/classes directory). If the average class size is, say, 3K, and if there are 30K classes, then that will put the application size at at least 90M, which will take time to expand and to copy into the deployment location. However, that cost is only during deployment.
Note of thanks to Thomas Bitonti and David W. Hare for providing this information
The cost of having a large number of classes depends strongly on details of how the classes are present in the application, and whether Java EE5 features are enabled, and whether scanning is left enabled on all of the classes.
1) If the classes are exposed in a web module archive "WEB-INF/classes" directory, that will cause very large slowdowns. The converse is for the classes to be in a JAR, either in a simple utility JAR directly contained by the application archive (EAR file), or for the classes to be contained within an EJBJar, or for the classes to be contained in a JAR beneath a web module archive "WEB-INF/lib" directory.
2) If javaEE5 processing is enabled for the classes, either because the classes are present in a javaEE5 enabled EJBJar or WAR, that will cause large slowdowns. The converse is for the classes to be present in a location which will not be scanned, for example, if there is a "META-INF/application.xml" for the EAR, and if all of the modules use a pre-javaEE5 version, or if all of the modules are marked as metadata-complete.
3) Even if javaEE5 processing is enabled, if a large subset of the classes do not require annotation scanning, that can be disabled using special properties in the application and module "META-INF/MANIFEST.MF" manifest files.
4) If using WAS version 7, please upgrade to fixpack 7.0.0.13 or later. We put in some optimizations in 7.0.0.13 to make the reading and writing to disk of applications much more efficient. Large apps (like Commerce) that are over 100 MB in size deployed 30-40% faster.
5) Check if the application is EE5 (in the application.xml, look for the version= tag). If so, check if there are any WAR files inside the EAR that contain numerous JARs under WEB-INF/lib. If those are present they can increase deployment time significantly. There is a tuning option available to help, and it's documented here PK87053: JAVA ENTERPRISE EDITION VERSION 5 APPLICATIONS TAKE A LONG TIME TO DEPLOY http://www-01.ibm.com/support/docview.wss?uid=swg1PK87053
When deploying the application, there will be an unavoidable cost of copying the application files during deployment, which will be proportional to the total size of the classes (but not proportional to the number of classes, unless these are exposed in a WEB-INF/classes directory). If the average class size is, say, 3K, and if there are 30K classes, then that will put the application size at at least 90M, which will take time to expand and to copy into the deployment location. However, that cost is only during deployment.
Note of thanks to Thomas Bitonti and David W. Hare for providing this information
Archives
December 2006 September 2008 January 2009 February 2009 March 2009 September 2009 October 2009 November 2009 December 2009 January 2010 February 2010 March 2010 April 2010 October 2010 January 2011 February 2011 April 2011 May 2011 June 2011 July 2011 August 2011 September 2011 October 2011 November 2011 December 2011 January 2012 February 2012 March 2012 April 2012 May 2012 June 2012 July 2012 August 2012 September 2012 October 2012 November 2012 January 2013 May 2013 June 2013 July 2013 September 2013 October 2013 June 2014 August 2014
Subscribe to Posts [Atom]
Post a Comment
Note: Only a member of this blog may post a comment.