All Things WebSphere

Concerns and issues relating to all versions of WebSphere Application Server

Monday, March 8, 2010

WebSphere Tuning

Ever wonder what WebSphere application server tuning needs to be done before deploying an application in production. Take a look at this whitepaper from the WebSphere performance team: ftp://ftp.software.ibm.com/software/webservers/appserv/WASv7_Tuning_Script_Templates_v1.0.pdf

"A new set of optimized performance tuning scripts are now available for download on the WebSphere® Application Server Performance site and included within the latest update to the WebSphere Application Server Base Trial v7.0.

These python-based tuning scripts can be used in conjunction with wsadmin to apply recommended tuning settings for three standard tuning templates. These standard tuning templates are designed to target individual server instances and apply some of the most common WebSphere Application Server tuning parameters to suit one of the following three environments"

posted by Rohit Kelapure # 9:21 AM 0 Comments

Pimp my websphere ... Reduce WebSphere Application Server startup time

If you do a lot of JEE application development on WebSphere Application Server (WAS) and cannot afford Rational Application Developer, you will often find yourself restarting WAS and wondering why you have to deal with restarting the server all the time. Why not save some time and develop on Tomcat or some other app server. As a developer in WAS, I face the same issues.

To help with this situation here is a cheat sheet to reduce your application server stop and start time. PLEASE NOTE THIS ADVICE IS ONLY MEANT WHEN DEVELOPING IN A SANDBOX environment. Some of these tips are illegal in 24 states... <just kiddin!>

1. Turn ON parallel start of the server. (default is true). Start the server on multiple threads. To view this administrative console page, click Servers > Application servers > server_name.

2. Server Component Provisioning: Start components when needed. Components started as they are needed by an application that is running on this server.

3. Run in development mode. Specifies that you want to use the JVM properties -Xverify and -Xquickstart on startup. Before selecting this option, add the -Xverify and -Xquickstart properties as generic arguments to the JVM configuration.

4. Set the JVM -Xms option equal to -Xmx to a value that is equal to your working set of your heap. Usually 1024MB is enough for development. Look at JVM tuning.

5. Uninstall all applications you don't need. Including system applications like the WebSphere admin console.

If uninstall is not an option then disable automatic start of applications.

wsadmin.sh –f deployConsole.py remove

6. Disable admin and application security.

7. Turn OFF the PMI service. PMI data collection is used to diagnose problems and tune application performance.

8. Turn OFF ODC Service. See APAR PM07711: Allow the initialization of the On Demand Configuration component to be bypassed

9. Turn off the Dynacache Service in WAS v8 if you are NOT using caching. This is only possible in WAS v8.

10. Disable the WebSphere Application Server service log/activity log. This service is not essential to WAS and very few system administrator make use of the activity / service log. See on how to disable this service. This is the default in WAS v8.

11. Disable HAManager. If none of the HA manager related services are being leveraged by your
application or environment, the service can be disabled to eliminate the associated overhead.

Labels: server performance

posted by Rohit Kelapure # 6:36 AM 0 Comments

Friday, March 5, 2010

Getting jconsole working with WebSphere Application Server

WebSphere application Server does NOT have good tools to deal with JMX mbeans exposed by WebSphere component services. The jConsole utility provided by the JVM gives us a window to all the WebSphere JMX Mbeans and helps execute operations on the mbeans using a console. This is a precursor to any admin work using wsadmin $AdminControl operations. A script has been provided below for getting jconsole working with WebSphere Application Server 7.0.0.*

This script has been validated with WebSphere Application Server 7 on windows with no admin. security. Make appropriate changes to get it running in unices. Please set HOST_NAME, RMI_CONNECTOR_PORT and WAS_HOME before running this script. All these three are available in the WebSphere Application Server SystemOut.log

echo service:jmx:iiop://localhost:2809/jndi/JMXConnector
set HOST_NAME=localhost
set RMI_CONNECTOR_PORT=2819
set WAS_HOME=C:\was7\install
set JAVA_HOME=%WAS_HOME%\java
set CLASSPATH=%CLASSPATH%;%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%WAS_HOME%\runtimes\com.ibm.ws.admin.client_7.0.0.jar;
%JAVA_HOME%\bin\jconsole.exe -J-Djava.class.path=%CLASSPATH% service:jmx:iiop://%HOST_NAME%:%RMI_CONNECTOR_PORT%/jndi/JMXConnector

posted by Rohit Kelapure # 12:29 PM 0 Comments

Dynacache cache content not replicating

In order to replicate content across WebSphere cluster members, a DynaCache cache instance has to be setup for replication. The cache instance has to be associated with a replication domain and optionally also a sharing type i.e. a replication type. Even after doing this many time cache replication does not seem to work across cluster members.

This is a checklist of things to look @ if cache content is not replicating

1. Check the configuration of the cache instance. Cache instance should be associate with a replication domain when the cache-instance is defined.

2. Check the sharing type of the objects put int the cache. Note that the sharing type of a cache object specified on an API call or the cachespec.xml file overrides the sharing type of the cache instance which in turn overrides of the sharing type of the replication domain.

3. DRS may not have finished bootstrapping the cache instances. Take a look @
http://tinyurl.com/yzyv7q9
In WAS7 you can set the JVM custom property "com.ibm.ws.cache.CacheConfig.createCacheAtServerStartup" to "true"

4. If all else fails turn on tracing for "com.ibm.ws.cache.*" and grep the trace*.log for "publish" to see if Dynacache is pushing the objects to DRS.

In 9 times out of 10, cache content not replicating false into the first three reasons given above.

posted by Rohit Kelapure # 11:44 AM 0 Comments

Poor man's way to improve WebSphere performance

Using WebSphere Dynacache servlet caching feature you can improve the performance of your web application by 20-100% by enabling servlet caching and just writing a cache specification file aka a cachespec.xml and dropping it in your WEB-INF or META-INF dir. of your application.

posted by Rohit Kelapure # 5:41 AM 0 Comments

WebSphere JVM memory sizing and monitoring methodology on zOS

Memory Sizing Methodology for zOS External

posted by Rohit Kelapure # 5:19 AM 0 Comments

Tuesday, March 2, 2010

Dynacache flight recorder wsadmin script

To debug problems or examine the performance characteristics of Dynacache over long runs, we use a wsadmin script to collect cache statistics exposed by the Dynacache mbean at a periodic interval. Looking at these statistics helps understand the state of the cache and troubleshoot any performance issues in the operation of Dynacache. These statistics also help in tuning the cache and improving its effectiveness.

For those customers interested in a deep-dive of cache internals and operations and a wsadmin script for monitoring Dynacache I have provided the script here. The overhead of the script is less than 1%. It is retrieving current cache statistics from the Dynacache mbean. It is acceptable to run this script in a production environment.

The script accepts several parameters required and optional:
-nodeName - The name of the server node. This parameter is required only if the server name is not unique in the cell.
-cacheInstance -The JNDI name of the cache instance for which statistics will be collected. If not specified, statistics will be collected for the base cache only. "*" indicates all cache instances.
-sleepUnit -The unit for sleep intervals. Possible values: hours, minutes or seconds. Default is seconds.
-sleepInterval - The number of sleep units between polls. Default is 10.
-fileAppend - If specified, statistics are appended to the file, if it already exists. Otherwise, the file is recreated. optional
-csvSeparator - The character used for the CSV field separator. Default is ",". optional
-cacheType - An optional filter on caches. A single character should be specified as its value. A value of w or W or m or M specifies WXS-DynaCache, whereas a value of t or T specified traditional Dynacache. By default there cache filtering is turned off. The filter can be conveniently used with the 'cacheInstance' parameter. A parameter combination "-cacheInstance * -cacheType w" will collect statistics for all the configured WXS DynaCache instances in the environment

Usage:
./wsadmin.sh -lang jython -f DynaCacheStatisticsCSV.py <SERVER_NAME> <LOG_FILE> "-nodeName <NODE_NAME> -cacheInstance <*|CACHE_INSTANCE_NAME> -sleepUnit <hours|minutes|seconds> -sleepInterval <SLEEP_UNITS> "

Sample Usage:
nohup ./wsadmin.sh -user -password -lang jython -f DynaCacheStatisticsCSV.py WC_wcsperf1 /wcsuser/scripts/dcmon/disk_cache_debug.log "-nodeName app11 -cacheInstance baseCache -sleepUnit minutes -sleepInterval 5" &

WC_wcsperf1 is the server name, app11 is the node name and /wcsuser/scripts/dcmon/disk_cache_debug.log is the file that contains the recorded statistics.

Please verify that the cache statistics file is being written too once the wsadmin script is kicked off. Once the test run is over suck the cache statistics log file into microsoft excel or open-office as a CSV file and graph the relevant statistics. Interpretation of the statistics will be in a subsequent blog post.

posted by Rohit Kelapure # 8:12 AM 0 Comments

Connecting sun visualVM to WebSphere

To get Sun's visual VM tool working with WebSphere read this post

posted by Rohit Kelapure # 7:35 AM 0 Comments