Wednesday 24 May 2017

Performance Tuning of Websphere Application Server

Application Server:   An application server is a framework that provides necessary environment and infrastructure for executing your enterprise applications.
WebSphere Application Server:  A product of IBM, is the leading software application server especially for service oriented application (SOA) services and applications for your business.

You can build business critical enterprise solutions and provide innovative functionalities with WAS.
Customers can use WAS to create and manage complex applications and dynamic websites.

Below diagram shows the WAS infrastructure.

Source : Internet





Performance is one of the major requirements of WAS environment. All necessary load tests should be performed before rolling out the project to go-live. Success criteria should be set before evaluating the product.


After running the defined tests, if all the performance requirements are met, the test can be considered as successful by running one more similar test. Else, you need to collect & analyse the logs and traces using top down approach till you identify the bottleneck. Apply the required tuning suggestions and run the test again.
if the test meets the objective, ensure that you have planned the future growth to meet the performance goals.

Common Targets for success criteria:


1. Throughput :  Number of requests servers by the application in a unit time. If an application has the ability the process the request for 1000 customer requests simultaneously in a single second, then the potential throughput of the application can be 1000 requests/sec.


2. Response time :  The time from entering a system boundary and exit the boundary is measured as response time.  Ex - Request sent from the browser and response received in the browser for an user.


3. Batch Processing : Batch feeds should be completed within the required time frame with all the production like background load running in the applications. Batch applications usually execute during the non peak hours to avoid stressing the resources with online load and getting the application slowed for end customers.



Tuning Recommendations for WAS - Referred from IBM Learning Center

Before getting into application tuning, lets do understand the components where common bottlenecks can be found.

1. Session Replication

2. Controlling memory buffers
3. Workload Management
4. Security Configurations
5. High Availability.

1. Session Replication: Copying the session data to a remote store is called session replication. This remote store can be a database or a WebSphere instance depending on whether you use database distributed sessions or memory-to-memory replications. If there is an issue with ongoing session, another process can use the backed-up session to serve the request to facilitate the end user an uninterrupted browser experience.


Tuning Recommendations:  


Keep it under 1 MB in all possible cases.

Only should be storing information critical to users specific interaction with Server. Three factors to be considered while session replication is enabled in WAS.

         A. Write Frequency : It defines how frequent the sessions are replicated to the remote area. Application performance degrades with high frequency as more CPU cycles being used for replicating the sessions rather serving the requests. There are three options to write the sessions data.
    • Time based (default) - Write session data in fixed period of intervals. If a user makes 10 requests between the intervals, a single update can replicate the data. This option should be selected for performance benefits over other options in general conditions.
    • Manual Update : Write the session data only when the servlet calls the IBM.session.sync method. Not ideal option in production, best to be used in development environment.
    • End of service servlet: Write the session data at the end of servlet service call. You can use this option for fail-over support and maximum reliability.
        B. Write Contents: This flexibility allows for fewer code changes for the JSP writer when the application is being operated in a clustered environment. 
    • Write Changed (Default) : Write only session data properties that have been updated through setAttribute and RemoveAttribute method calls. This option should be selected for performance benefits over other option.
    • Write All: Write all the session data properties. Only advised to be used if SetAttribute method call fails. For better performance using this option, combine it with Time-based write.
        C. Session Time Out: Specifies the validity of a session. The default value is 30 minutes. However this value can be overwritten as per the application requirement. Timeout should be optimized to enable unused sessions to be invalidated quickly. When the write frequency is time based, make sure to keep the interval at least twice of the large interval.

2. Controlling memory buffers: Every messaging engine manages two memory buffers that contains messages and message related data. The performance can be improved by tuning the interaction between messaging engine with its data store by configuring these buffer size.


  • sib.msgstore.discardableDataBufferSize: Increasing the size of the discardable data buffer allows more best effort nonpersistent data to be handled before the messaging engine begins to discard messages.
  • sib.msgstore.cachedDataBufferSize:The purpose of the cached data buffer is to optimize the performance of the messaging engine by caching in memory the data that the messaging engine might otherwise have to read from the data store. As it writes data to the data store and reads from the data store, the messaging engine attempts to add that data to the cached data buffer. The messaging engine might discard data already in the buffer to make space
  • sib.msgstore.transactionSendLimit:The maximum number of operations that the messaging engine includes in each transaction. For example, each JMS send or receive is an operation that counts towards the transaction send limit. The default value is 100

3. Workload Management: The process of sharing requests across multiple resources is called as Workload Management. Two main features of workload management is 'Load Balancing' and 'Affinity'.

Load Balancing -  The capability of sending requests to alternate instances is called Load balancing. The feature is required to avoid potential bottle-necked instances and overloaded instances.

Affinity - It denoted the ability to route concurrent requests to the instance that served the first request.
Available load balancing options are Round-robin and Random. Round-robin works on the principle of the weight associated the cluster members. When the cluster member is selected randomly by the lug-in is called as Random load balancing.

4. Security Configuration: Security configuration can be tuned to balance performance with functionality. Need to understand the type of security configurations and what other things to be enabled/disabled to maintain a balanced performance without compromising the security. 

Ex -  SSL layer can be disables while working in a VPN ; Java2 security manager can be disables if you are aware of exact code is deployed in the server. 
Maintain same security configs across all nodes.
If the environment is secured, the token time out and cache can be increased to reuse credentials and less timed outs. 
Its recommended for the administrative connector to use Stateful connections over stateless connections.

5. High Availability:  The ability of a system to tolerate certain number of failures and still remains operational is known as High Available system.

High availability could be achieved by adding redundancy in the infrastructure to handle most of the failures. Availability has a direct impact on the performance and scalability.

Availability = (MTBF/(MTBF + MTTR)) X 100


MTBF is the mean time between failures.


MTTR is the maximum time to recovery.