All Things WebSphere
Concerns and issues relating to all versions of WebSphere Application ServerMonday, August 1, 2011
Solving an application performance slowdown or regression with WebSphere Application Server
Recently I had the chance to troubleshoot and fix a performance regression a component of the WebSphere Application Server. The objective was to determine performance and locking hotspots in our server code.
1. Beg, borrow steal or write a benchmark. We already have a pretty good Dynacache performance benchmark. This is critical to draw a line in the sand and determine a before and after performance #s.
2. Enable IBM Health Center profiling. Using IBM Health Center which is baked into the WAS JVM, is the easiest and lightest way of doing profiling with WebSphere Application Server. No expensive profiling tools and no instrumentation of src. This is best thing since baked bread for performance in WAS.
3. So you need two things for this exercise. On the client side you need an IBM Health Center Client that comes as a free product plugin to the IBM Support Assistant. On the server side you need IBM Health Center server library which comes preinstalled with the JVM which is bundled with WAS. You will find one WAS_HOME/java/jre/lib/ext/healthcenter.jar
4. Configure WAS to use the IBM Health Center. See details in Infocenter for older versions of java.
Servers ->Server Types -> WebSphere application servers. Select the server name and then select Java and Process Management -> Process definition -> Java Virtual Machine -> Generic JVM Arguments.
For Java 5 SR10 and later, or Java 6 SR5 and later, use:-Xhealthcenter
5. After restaring WAS, start the ISA and configure a connection to your WAS server. This connection is established typically on port 1872. If you want to control the server port see infocenter. After the JVM is started with the agent enabled, you see a message detailing the port for the Health Center agent. For example:
05-Mar-2009 09:49:57 com.ibm.java.diagnostics.healthcenter.agent.mbean.HCLaunchMBean startAgentINFO: Health Center agent started on port 1972.
6. Run the benchmark or the test.
7. After the test save the profile as a *.hcd file. You can then pass this profile around and analyze it offline. See technote.
8. Interpret the method profile. The Method Profile table shows which methods are using the most processing resource.
Happy profiling!
1. Beg, borrow steal or write a benchmark. We already have a pretty good Dynacache performance benchmark. This is critical to draw a line in the sand and determine a before and after performance #s.
2. Enable IBM Health Center profiling. Using IBM Health Center which is baked into the WAS JVM, is the easiest and lightest way of doing profiling with WebSphere Application Server. No expensive profiling tools and no instrumentation of src. This is best thing since baked bread for performance in WAS.
3. So you need two things for this exercise. On the client side you need an IBM Health Center Client that comes as a free product plugin to the IBM Support Assistant. On the server side you need IBM Health Center server library which comes preinstalled with the JVM which is bundled with WAS. You will find one WAS_HOME/java/jre/lib/ext/healthcenter.jar
4. Configure WAS to use the IBM Health Center. See details in Infocenter for older versions of java.
Servers ->Server Types -> WebSphere application servers. Select the server name and then select Java and Process Management -> Process definition -> Java Virtual Machine -> Generic JVM Arguments.
For Java 5 SR10 and later, or Java 6 SR5 and later, use:-Xhealthcenter
5. After restaring WAS, start the ISA and configure a connection to your WAS server. This connection is established typically on port 1872. If you want to control the server port see infocenter. After the JVM is started with the agent enabled, you see a message detailing the port for the Health Center agent. For example:
05-Mar-2009 09:49:57 com.ibm.java.diagnostics.healthcenter.agent.mbean.HCLaunchMBean startAgentINFO: Health Center agent started on port 1972.
6. Run the benchmark or the test.
7. After the test save the profile as a *.hcd file. You can then pass this profile around and analyze it offline. See technote.
8. Interpret the method profile. The Method Profile table shows which methods are using the most processing resource.
- Methods with a higher Self (%) value are described as "hot", and are good candidates for optimization. Small improvements to the efficiency of these methods might have a large effect on performance. Methods near the bottom of the table are poor candidates for optimization. Even large improvements to their efficiency are unlikely to affect performance, because they do not use as much processing resource.
- You can optimize methods by reducing the amount of work that they do or by reducing the number of times that they are called. Highlighting a method in the table populates the call hierarchy views.Filter the contents of the method profile table using the text box above the table. See the filtering help topic for more information.
- Additionally, when you select the Hide low sample entries, the table does not list any entries that have a sample count of less than 2. Use this option if your table contains many entries that are not obvious candidates for optimization to improve the performance of the table.
9. Make java source code changes to improve performance. Scrub and repeat. We used the process above to take before and after profiles to figure out the delta i.e .where the performance had slipped.
Happy profiling!
Labels: application performance
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.