All Things WebSphere

Concerns and issues relating to all versions of WebSphere Application Server

Sunday, February 28, 2010

What should be the size of your HTTPSession ?

A lot of JEE application developers and WebSphere system administrators struggle to establish a size for the HTTPSession. It is a recommended best practice to keep session data sizes small and leverage a POJO cache like the Dynacache Distributedmap to store long running data.

Section 12.10.1 of WebSphere Application Server V7 Administration and Configuration Guide gives the following guidance on session size: "In general, you can obtain the best performance with session objects that are less than 2 KB in size. When the session object exceeds 4-5 KB, you can expect a significant decrease in performance."

I believe this advice is correct in intent but should not be taken literally. The part of that quote that is misleading is the text "When the session object exceeds 4-5 KB, you can expect a significant decrease in performance." This is not necessarily true in all cases as the ideal HTTPSession size varies by application and depends on the performance characteristics and function of the application.

Even if session persistence is not an issue, minimizing the session object size will help protect your Web application from scale-up disasters as user numbers increase. Large session objects will require more and more JVM memory, leaving no room to run servlets.

If you are a system administrator and need to determine How big your WebSphere HTTP sessions are? ( and what's in them?) read this excellent L3 session troubleshooting blog post from WebSphere Java guru Chris Bailey.

If you are a architect and need to determine an overall strategy for HTTPSession size and persistence read Chapter 12 in the WebSphere 7 Administration and Configuration redbook as well as this session persistence article from Erik Burckart.

For profiling the HTTP session sizes using OQL in Memory Analyzer

SELECT data as "MemorySessionData", 
 data.@usedHeapSize as "Heap Size", 
 data.@retainedHeapSize as "Retained Heap Size",mSwappableData, 
 toString(data.mManager.scAppParms._J2EEName) as "J2EE Name", 
 toString(data.appName) as "App Name", 
 toString(data.mSessionId) as "Session ID" 
 FROM com.ibm.ws.webcontainer.httpsession.MemorySessionData data

These resources together with the WebSphere Infocenter articles on session persistence will help you establish the right session persistence strategy and size for your application.

Please also see WebSphere Session Persistence Best Practice blob post.

Labels: session

posted by Rohit Kelapure # 8:45 PM 0 Comments

Thursday, February 25, 2010

Presentation on the tools available for managing Dynacache

Cache Tooling

posted by Rohit Kelapure # 10:07 PM 0 Comments

Caching webservices responses in WebSphere Application Server with Dynacache service

Caching as a best practice to improve response times and reduce CPU utilization is well-established.
There are two aspects to caching webservices responses in WebSphere Application Server with Dynacache Responses can be cached on the client side or on the server side. To enable webservices caching follow the steps listed below:

Enable the dynamic cache service on the web container of the application server from: Application Servers --> Web Container --> Enable servlet caching
Provide a cachespec.xml file in the WEB-INF directory of the webservice web project. This will contain the caching information toWebSphere. See below for what this file should contain
Display cache information using the Cache monitor. This can be installed from the WebSphere installableApps directory

The following request options are available for creating a cache policy to cache webservices: Find the full list of supported cache policy parameters in the cachespec.xml here

SOAPAction	Web service	Retrieves the SOAPAction header, (if available), for a Web services request.
serviceOperation	Web service	Retrieves the service operation for a Web services request
serviceOperationParameter	Web service	Retrieves the specified parameter from a Web services request
operation	Web services client cache	An operation type in the Web Services Description Language (WSDL) file. The `id` attribute is ignored and the value is the operation or method name. If the namespace of the operation is specified, the value should be formatted as namespaceOfOperation:nameOfOperation
part	Web services client cache	An input message part of in the WSDL file or a request parameter. Its `id` attribute is the part or parameter name, and the value is the part or parameter value.
SOAPHeaderEntry	Web services client cache	Retrieves special information in the Simple Object Access Protocol (SOAP) header of the Web services request. The `id` attribute specifies the name of the entry. In addition, the entry of the SOAP header in the SOAP request must have the "actor" attribute which contains `com.ibm.websphere.cache`. For example: <soapenv:Header> <getQuote soapenv:actor="com.ibm.websphere.cache">IBM</getQuote> </soapenv:Header>

WebServices Client side caching:
Dynacache runtime has an inbuilt client side JAX-RPC cache handler that intercepts received responses and caches it based on a cache policy specified in the cachespec.xml. You will need to use the JAXRPCClient class in the cachespec.xml to cache server-side webservices responses. Excellent article on client-side webservices caching Sample cachespec.xml and corresponding wsdl file:

<cache>
 <cache-entry>
  <class>JAXRPCClient</class>
  <name>http://TradeSample.com:9080/service/getquote</name>
  <cache-id>
   <component id="hash" type="SOAPEnvelope"/>
   <timeout>60</timeout>
  </cache-id>
 </cache-entry>
</cache>

WebServices server side caching:
Dynacache intercepts a server side webservices response. You will need to use the webservice class in the cachespec.xml to cache server-side webservices responses. Sample cachespec.xml and corresponding wsdl file:

<cache>
<cache-entry>
 <class>webservice</class>
 <name>/services/DataProxy</name>
 <sharing-policy>not-shared</sharing-policy>
 <cache-id>
  <component id="id" type="serviceOperationParameter"/>
  <timeout>3600</timeout>
  <priority>1</priority>
 </cache-id>
</cache-entry>
</cache>

Caching of WebServices responses ONLY works for JAX-RPC style webservices and SOAP1.1 responses. For caching ANY webservices response including ones based on the JAX-WS , JAX-RPC on SOAP 1.1 or SOAP1.2 you can use custom Java code to build the cache id from input SOAP message content.

If you use custom Java code to build the cache id, create an ID generator Java class that implements the IdGenerator interface defined in the com.ibm.websphere.cache.webservices.IdGenerator package and add a reference to the class you create in the cachespec.xml file by using the idgenerator tag. You can also optionally implement the com.ibm.websphere.cache.webservices.MetaDataGenerator package to assign cache metadata such as timeout, priority, and dependency ids to cache entries using the metadatagenerator tag as well as implement the Implement the com.ibm.websphere.cache.webservices.InvalidationGenerator interface and use the invalidationgenerator tag in the cachespec.xml file to generate cache ids and to invalidate entries in the cache. The id generated by the invalidation generator can be a cache id or a dependency id.

src code: Client IdGenerator :
sample idgenerator cachespec.xml for client side webservices response caching:

<cache-entry>
 <class>JAXRPCClient</class>
 <name>http://TradeSample.com:9080/service/getquote</name>
 <cache-id>
  <idgenerator>com.mycompany.SampleIdGeneratorImpl</idgenerator>
  <metadatagenerator>
       com.mycompany.SampleMetaDataAndInvalidationGeneratorImpl
    </metadatagenerator>
  <timeout>60</timeout>
 </cache-id>
 <invalidation>http://TradeSample.com:9080/service/GetQuote
  <invalidationgenerator>
       com.mycompany.SampleMetaDataAndInvalidationGeneratorImpl
    </invalidationgenerator>
 </invalidation>
</cache-entry>

src code on git: webservices IdGenerator for serverside caching
sample idgenerator cachespec.xml for server side webservices response caching:

<cache>
<cache-entry>
        <class>webservice</class>
        <name>/Services/MyService</name>
        <sharing-policy>not-shared</sharing-policy>
        <cache-id>
                <timeout>600</timeout>
                <priority>1</priority>
   <idgenerator>
    com.ibm.my.WS_IdGenerator
   </idgenerator>
        </cache-id>
</cache-entry>
</cache>

This IdGenerator class has to be bundled as a shared library and associated with an application server. Follow the steps below to add the idgenerator as a shared libarary to your server
1. Select an application server.
2. In the Server Infrastructure section, expand the Java and ProcessManagement. Select Class loader.
3. Choose New, and select a class loader order for this class loader, Classes loaded with parent class loader first or Classes loaded with local class loader first (parent last). Click OK.
4. Click the class loader that is created.
5. Click Shared library references.
6. Click Add, and select the library you want to associate to this application server. Repeat this operation to associate multiple libraries to this class
loader.
7. Click OK.
8. Save the configuration.
9. Restart the application server for the changes to take effect.

Takeaway: WebServices caching can yield performance benefit to the tune of an order of magnitude. 100%, 200% improvement for exteremely heavy responses is not unusual. Leverage the free cache of WebSphere i.e. Dynacache and ALL its tooling CacheMonitor, Extended Cache monitor, PMI statistics and the JMX mbean to cache, administer and manage your webservices responses.

posted by Rohit Kelapure # 1:03 PM 0 Comments

Monday, February 22, 2010

ALL you wanted to know about WebSphere Dynacache caching and more ...

WebSphere Dynacache Redbook

Fast Response Cache Accelerator:

End-to-End Performance of a WebSphere Environment Including Edge Components

Tuning WebSphere Application Server Cluster with Caching

WebSphere Dynacache Redbook

WebSphere Performance and Scalability Chapter 10

WebSphere Dynamic Cache: Improving J2EE application performance

Caching Methodology

Caching Tutorial

Caching White Paper

Static and dynamic caching in WebSphere Application Server V5

Chapter 5 in

White Paper: Caching WebSphere Commerce pages with the WebSphere Application Server dynamic cache service

Dynacache DRS Tuning Guide:

Caching guide to Edge Applications

Dynacache MustGather documents and Problem Determination Guide

More must gather

TecDocs:

Developerworks:

posted by Rohit Kelapure # 8:03 AM 0 Comments

Dynacache and the Edge Side Include (ESI) cache in WebSphere

WebSphere ESI is a static and dynamic cache at the edge of the network. This cache resides in the WebSphere Proxy or the WebSphere plugin. The cache is managed by the Dynacache component of the WebSphere Applications Server. For details of how to configure ESI caching, refer to the “Configuring Edge SideInclude caching” section in the WebSphere Application Server Information Center.

ESI can cache static as well as dynamic content:

Static caching with ESI: Well explained here: http://www.ibm.com/developerworks/websphere/techjournal/0405_hines/0405_hines.html All the static content of WAS(images, javascript, pdf's) is cached in the Plugin ESI cache if static caching is enabled.
Dynamic caching with ESI: All the includes in the JSP/Servlet/JSF are replaced with esi:includes that are fluffed up and cached by the WebSphere plugin ESI cache.The ESI cache can contain whole pages or fragments. It will dynamically assemble Web pages containing ESI tags from your existing application.

The ESI cache (static and dynamic) in the WebSphere plugin or the WebSphere proxy can be monitored and administered using the WebSphere Cache monitor. ESI Cache statistics can been viewed in the cache monitor. The DynaCacheEsi.ear application along with the plugin/proxy is responsible for maintaining the backend communication channel for invalidating the cache. This application MUST be installed for cache content in the ESI cache to remain fresh i.e. for items to expire and to be invalidated by WebSphere Application Server. Once the ESIInvalidationMonitor plugin-cfg.xml property is set to true (for invalidations flow back to the ESI processor), then a long-running connection is maintained from each process to the ESIInvalidatorServlet in each application server cluster.

Plugin/Proxy-WAS interaction on the long running thread
On the first request to the plugin for a particular app server virtual host, the plugin checks to see if a connection has been made to the ESIInvalidatorServlet and if not establishes a long running connection to that particular virtual host. Therefore if the plugin is communicating with the app. server on the http and https ports then each webserver plugin process will establish 2 ESI connections to the app. server. If there are 6 web server plugin processes then there are correspondingly 12 ESI connections to the application Server. Each long running connection runs/blocks a webcontainer thread on app. server and therefore "hung thread" messages for webcontainer threads appear in the SystemOut.log when ESI is enabled.

- The The ESIProcessor WebContainer thread will only be reported once time as being hung. Once the thread is flagged as hung it is not checked again and never reported again. However, if the thread was returned to the pool and reused its status would be reset and be subject to being reported as hung again.
- Every 45 seconds the ESIProcessor webcontainer thread requests the webserver's PID and then reads on the input data stream. The read will either return the webserver's response or an exception. There is no timeout of the read. If the connection is up a response will be return, if not, an IOException occurs and the long running connection is torn down releasing the webcontainer thread.

Read more about configuring ESI and Dynacache here

posted by Rohit Kelapure # 7:38 AM 0 Comments

Caching On Zos

Want to reduce your CP and ZAAP utilization on zOS ? Check out this presentation for WebSphere Application Server (WAS) on zOS

Caching On Zos

View more presentations from kelapure.

posted by Rohit Kelapure # 6:51 AM 0 Comments

Troubleshooting tips for Dynacache

Sometimes the Dynacache com.ibm.ws.cache.CacheConfig.InvalidationAuditDaemon (IAD) can holds a significant amount of memory on the JVM heap.
InvalidationAuditDaemon is a temporary bucket for all the invalidations flowing the system. These invalidations are held by default for a period of 5 minutes. The amount of heap consumed by IAD grows and shrinks. These remembered invalidation events are used to check for duplicate or older invalidations.
Set the JVM custom property "com.ibm.ws.cache.CacheConfig.timeHoldingInvalidations" to "120000" msec (2min.) to reduce the footprint and variance of the Dynacache InvalidationAuditDaemon.

Reducing timeHoldingInvalidations reduces the # of invalidation events Dynacache remembers.

Labels: l3

posted by Rohit Kelapure # 6:30 AM 0 Comments

All Things WebSphere

Sunday, February 28, 2010

What should be the size of your HTTPSession ?

Thursday, February 25, 2010

Presentation on the tools available for managing Dynacache

Caching webservices responses in WebSphere Application Server with Dynacache service

Monday, February 22, 2010

ALL you wanted to know about WebSphere Dynacache caching and more ...

Dynacache and the Edge Side Include (ESI) cache in WebSphere

Caching On Zos

Troubleshooting tips for Dynacache

Archives