WebSphere eXtreme Scale Best Practices for Operation and Management

2 WebSphere eXtreme Scale Best Practices for Operation and Management

1.1 Benefits of using WebSphere eXtreme Scale

Today’s dynamic business environment and economic uncertainty mean organizations must

work smarter to remain competitive and to respond to changing customer demands. The key

to working smarter is business agility and cost optimization. Organizations need to ensure

that crucial applications can meet the requirements of rapid increases in demand, can deliver

immediate and consistent responses, and can scale as necessary. There is also a need for

enhanced application performance to keep pace with rising customer expectations regarding

application response time while also managing the costs of the infrastructure.

Many challenges in meeting these demands center around data access. A standard three-tier

application will typically present the following challenges:

򐂰 Keeping system response time low while user load increases

򐂰 Dealing with a high database load that causes slow data access

򐂰 Scaling the current infrastructure as the data volume grows

򐂰 Dealing with a volume of data that is so large that it cannot be stored in a single, physical

system

򐂰 Maintaining the state in memory and replicating that state across multiple systems in

various data centers in case of failover

The solution to these challenges can be found with WebSphere eXtreme Scale. WebSphere

eXtreme Scale is an elastic, scalable, in-memory data grid. It allows business applications to

process billions of transactions per day with efficiency and near-linear scalability. The data

grid dynamically caches, partitions, replicates, and manages application data and business

logic across multiple servers and virtualization environments. With WebSphere eXtreme

Scale, you can also get qualities of service, such as transactional integrity, high availability,

and predictable response time.

1.2 Adoption of WebSphere eXtreme Scale

WebSphere eXtreme Scale provides a data grid to store data. How you access that grid, and

the type of data that you store in it can vary depending on the application. A detailed systems

and design analysis is required to determine if, when, and how you use WebSphere eXtreme

Scale. This analysis is an important exercise for devising a decision tree road map for

adoption of any new technology.

Chapter 1. Introduction to WebSphere eXtreme Scale 3

Figure 1-1 illustrates a decision tree that can help in this evaluation.

Figure 1-1 Decision tree for adopting WebSphere eXtreme Scale

The decision tree addresses the issues of inadequate response time, slow data access, data

volume issues that affect performance, and memory usage problems. Based on the analysis

of similar problems, the first tier in the tree suggests the type of solution that is appropriate at

an architectural level. The second tier in the tree suggests the usage pattern on how

WebSphere eXtreme Scale can be used to implement the solution. The third tier provides

information about the specific types of caching that might prove useful in resolving the

problem.

The problem categories shown in the decision tree are interrelated, in that high database load

leads to slow data access, which by itself is a cause of slow application response times.

Removing one scalability bottleneck by introducing caching or a more advanced data grid

solution often reveals another bottleneck. It might take a few iterations and a few uses of

WebSphere eXtreme Scale before the application meets its scalability targets.

The problems shown in the decision tree invite a number of incremental solutions, such as

tuning database settings for greater performance, optimizing queries, and scaling up

database servers. These solutions do not address the greater scalability limitations of the

application but rather move it toward the limits of the current architecture. The effectiveness of

these solutions depends on how inefficient the application currently is and the availability of

more powerful server equipment, both of which can quickly reach the point of diminishing

returns.

HTTP sessions

application data

cache

DynaCache

Use eXtreme Scale

as an application

cache or a side

cache

Data access layer

for applications

move processing

into grid

Use eXtreme Scale

as a data grid

Database cache

data access layer

for applications

Use eXtreme Scale

as a backend

system cache or

an inline cache

Response

time

Slow data

access

Data

volume

HTTP session offload

application data cache

offload

DynaCache offload

Use eXtreme Scale

to offload

application state

storage

Problem

Memory

usage

Architecture

decision

eXtreme Scale

usage pattern

Cache type

Analysis suggests

caching as an

option

Analysis suggests

database scaling

Analysis suggests

data access layer

performance tuning

Analysis suggests

external state

storage